Esse artigo faz parte da revista Java Magazine edição 29. Clique aqui para ler todos os artigos desta edição

OR: windowtext; FONT-FAMILY: Verdana">dos

Construa uma aplicação de banco de dados auto-contida, usando o SGBD relacional puro-Java doado pela IBM à comunidade open source e liderado pela Apache

Na série de artigos “Persistência Turbinada” (Edições 25 e 26), comentei que a introdução da JDBC foi o marco para que o Java começasse a ser considerado opção para o desenvolvimento de aplicações. Mas se isso é verdade, o próximo passo seria implementar o próprio banco de dados em Java – neste caso, um teste de fogo da capacidade da tecnologia para o desenvolvimento de “software de sistemas”. Esta categoria compreende as camadas mais baixas na pilha de software que sustenta as aplicações: sistemas operacionais, protocolos, middlewares, e também bancos de dados. Tais softwares se caracterizam especialmente pela necessidade de controle fino sobre os recursos do hardware.

Este requisito é facilmente satisfeito por linguagens “macro Assembler” como C, mas parece mais difícil para o Java, sem manipulação de ponteiros, alocação manual de memória, e acesso direto ao hardware e ao sistema operacional. O Java sacrifica tais recursos para favorecer a implementação simples e robusta de outros itens: orientação a objetos, garbage collection, APIs de alto nível, segurança e portabilidade binária total. Todavia, a evolução da tecnologia de JVMs (compiladores JIT e garbage collectors), bem como a introdução de novas APIs para tarefas de alto desempenho, como a java.nio no J2SE 1.4 ou a java.util.concurrent no J2SE 5.0, acabou compensando muitos daqueles recursos de programação de baixo nível.

Neste artigo, vamos explorar o Apache Derby, um SGBD (sistema gerenciador de bancos de dados) relacional open source e feito em Java puro. As capacidades do Derby ilustram muito bem que é possível implementar praticamente qualquer coisa em Java: como veremos, o Derby é comparável a muitos bancos de dados convencionais. Mas não é só: justamente por ser escrito em Java, em alguns casos podemos até observar algumas vantagens sobre SGBDs nativos.

O problema: aplicação demo

Para explorar o Derby, focamos na construção de um “demo” de um software, o que é um problema bastante relevante para muitas empresas: construir uma versão limitada de uma aplicação, que possa ser instalada e testada por clientes potenciais, sem nenhum esforço e suporte externo, além da necessidade mínima de instalar pré-requisitos. Nesse caso, para aplicações que necessitem de um banco de dados, o ideal é usar um banco "embutível". Assim, sua aplicação pode ter um arquivo de instalação único que já inclui tudo o que necessita: o código da aplicação, o banco de dados e até os arquivos da base de dados (ou "database").

O exemplo desenvolvido neste artigo será uma aplicação web J2EE, empacotada num arquivo war que pode ser instalado de forma trivial. Basta fazer o deploy do war da maneira adequada para seu container (por exemplo, no Tomcat e no JBoss, basta copiá-lo para o diretório de auto-deploy). Portanto, quem executar esta instalação não precisará instalar um SGBD, fazer uma carga inicial de uma base de dados, configurar permissões, ou qualquer outra ação.

Instalando e executando o Derby

Como a maior parte das aplicações puro-Java, a instalação do Derby é simples e direta. No site db.apache.org/derby, faça o download da distribuição binária da última versão estável do Derby (10.1.1.0, no momento de escrita) e descompacte o zip num local apropriado, por exemplo c:\Derby. Crie uma variável DERBY_INSTALL apontando para este diretório e certifique-se também que a variável JAVA_HOME aponte para a instalação do J2SE (JDK ou JRE).

Você verá que ao invés de apenas um subdiretório bin, a instalação do Derby cria dois: frameworks/embedded/bin e frameworks/NetworkServer/bin. Isto reflete a possibilidade do Derby funcionar de duas maneiras diferentes.

O modo Network

No modo Network, o Derby funciona como a maioria dos SGBDs: o servidor executa como um processo à parte e pode ser acessado pelos clientes via TCP/IP. Vários clientes simultâneos, no próprio ou em outros hosts, podem acessar o mesmo banco de dados. Para testar esse modo de operação, na linha de comando entre no diretório frameworks/NetworkServer/bin e execute:

> startNetworkServer

Esta é a mensagem exibida:

O servidor está pronto para aceitar conexões na porta 1527.

Isso mostra que o servidor foi iniciado com sucesso e informa o número da porta TCP/IP que está escutando (por padrão, 1527). É uma boa surpresa ver que o Derby já é internacionalizado para Português do Brasil (entre outros idiomas).

Agora vamos conectar ao servidor e fazer um teste simples de SQL. Em uma nova janela de linha de comando e dentro do mesmo diretório frameworks/NetworkServer/bin:

> ij

(... várias mensagens)

ij version 10.1

 

ij> connect 'jdbc:derby://localhost/c:\temp\testdb;create=true';

ij> select tablename from sys.systables;

TABLENAME

------------------------------------------------...

SYSALIASES

SYSCHECKS

SYSCOLUMNS

...

(Aqui e nos próximos exemplos, os comandos executados são realçados com negrito e as informações retornadas, com itálico.) O utilitário ij é um cliente de linha de comando simples, suficiente para acompanhar este artigo, mas você pode usar um cliente mais poderoso como o SQuirreL (também Java e open source).

O comando connect abre uma conexão com uma base de dados, sendo que o parâmetro exigido é uma URL JDBC (use “help;” para ver todos os comandos disponíveis). O Derby tem dois padrões de URL: para o modo Network, usa-se jdbc:derby://host[:porta]/database. Os colchetes, como de costume, indicam partes opcionais.

Cada base de dados no Derby é criada num diretório-raiz que a identifica. Mas como ainda não criamos nenhuma, utilizamos o atributo create=true na URL, o que faz com que o servidor crie a base caso ainda não exista. Após ter conectado, você pode verificar que o diretório correspondente foi criado. Voltando ao ij, executamos um comando SQL que consulta uma das tabelas do dicionário de dados do Derby, listando todas as tabelas existentes (numa base recém criada, só teremos as tabelas do próprio dicionário de dados[1]).

Além do ij, o Derby oferece outros dois utilitários de linha de comando. O sysinfo conecta ao servidor e exibe suas propriedades de configuração, e o dblook permite gerar a DDL para o esquema de uma base de dados.

O modo Embedded

No modo Embedded, o Derby funciona como uma biblioteca. Você coloca o jar do Derby no classpath da sua aplicação e, ao tentar conectar com o banco pela primeira vez, o “servidor” é inicializado no mesmo processo.

Vamos demonstrar isso novamente, com os scripts fornecidos com a distribuição do Derby. Primeiramente, interrompa os processos NetworkServer (com o script stopNetworkServer) e ij (com “exit;”). Depois, mude para o diretório frameworks/embedded/bin e comande:

>ij

ij version 10.1

ij> connect 'jdbc:derby:c:\temp\testdb';

ij> ...

Quer ler esse conteúdo completo? Tenha acesso completo