O David Berlind (ZDNet) publicou ontem um artigo com o seguinte título: "JavaDB: An idea whose time has finally come?". Ele fala algumas maravilhas do bichinho de código aberto, e 'lança-o' como a peça que faltava no quebra-cabeças das soluções thin-client. Saca só o parágrafo final:

"Furthermore, software developers have no motivation to turn those database technologies into file systems for storing productivity documents since, because of their limitations, they'll never be ubiquitously supported and the ROI of adding such a feature would be quite questionable. But, given it's dynamic nature, the ubiquity of browsers, and it's OS-agnosticism (by virtue of using a JVM), JavaDB could turn into that technology if only a few key developers prototyped the possibilities."

Há uns 4 anos mais ou menos estive envolvido num projeto que tinha entre seus requisitos principais:

• Capacidade de operar off-line...;
• ...em máquinas "antigas";
• E utilizar o mesmo código na solução on-line.

Tratava-se de uma solução para a sofrida área de seguros. Milhares de corretores de seguros, espalhados por todo o território nacional, deveriam ter condições de elaborar orçamentos e propostas no canal de sua preferência: web, kit de cálculo (off-line) ou telefone. Até hoje, em grande parte das seguradoras, cada canal significa uma solução diferente. Não é raro encontrarmos tecnologias totalmente diferentes também. Um urubulino me contou que em uma grande seguradora existem 18 (dezoito!) aplicações diferentes implementando as mesmíssimas regras de negócio (no caso desse negócio, regras de cálculo)!!

Nossa solução deveria demolir uma torre de babel semelhante, criando um único ponto para a criação/manutenção das regras. Qualquer dia conto mais detalhes sobre este projeto. O que importa aqui (neste post) é o desenho da arquitetura da solução. Tínhamos um produto de seguro (real) implementado em VB. Ele foi reescrito em Java e em C# para testes de laboratório. Nossa principal preocupação: encontrar o melhor desenho para o módulo off-line. O gráfico abaixo mostra nossas descobertas (tempo de cálculo em segundos - a menor barra indica o melhor resultado):



O HyperSonic era um SGBD (Sistema Gerenciador de Bases de Dados) 100% puro Java. Como é o JavaDB da Sun (que é uma derivação do Derby da Apache). Nosso projeto planejava sua utilização como um gerenciador de conteúdo não-estruturado também. Aliás, como um sistema de arquivos mesmo. As classes Java (para desespero de alguns puristas) residiriam no BD (para facilitar o gerenciamento de mudanças - vigências das regras de cálculo - que são um pesadelo para todos que lidam com projetos semelhantes).

Vendo hoje a atenção que o Berlind deu ao tema reforço minha crença: nosso projeto era e ainda é "visionário", hehe. Tanto nos aspectos técnicos quanto naqueles 'de negócio' (converse com qq corretor de seguros e vc entenderá).

Mas um dia, no meio do caminho (repleto de pedregulhos), ele foi cancelado. Um futuro artigo no finito tentará mostrar algumas das lições aprendidas. Aviso quando estiver pronto. Aqui, com a tag rendiconti (prestação de contas) que inauguro com este post, falarei mais deste e de outros projetos.