Este é um post disponível para assinantes MVP
dê seu feedback
post favorito
Artigo Java Magazine 29 - Demonstrando o Apache Derby
Artigo Publicado pela Java Magazine 29.
Demonstrando o Apache Derby
Aplicações Sofisticadas com Dados Embutidos
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 "
ATENÇÃO! A exibição deste artigo foi interrompida.
Este é um post disponível para assinantes MVP
Space do autor
0
0
