Curiosamente volume de dados nunca foi a razão pelo qual o prevayler não tinha razão. Uma delas foi latência e tempo médio de resposta, mas como pode isso ocorrer se o prevayler é tão super mais rápido nas consultas? Simples, o enorme uso de heap tornava o tempo de garbage collection proibitivo, um SGBD usa memória de maneira muito mas eficiente sob o viés do tempo para dar manutenção nela, esse sistema terminou com uma JVM usando 64Mb e a base toda dentro do cache do banco de dados. Outro problema foi confiabilidade, o log do prevayler não é protegido de partial writes e usa statement based logging, que não permite recuperação parcial, então se tua controladora corromper o meio do teu log, você se lascou. Porém o maior problema do prevayler é o desenvolvimento com equipes distribuídas ou de médio porte em uma estrutura matricial de projetos, isto é, o esforço de coordenar schema evolution é massacrante, não existe como compartilhar facilmente uma base de dados e a integração entre projetos é infernal.

Quanto ao fato de Java ser uma péssima escolha, primeiro pelo fato de não ser uma linguagem baseada em imagem, como smalltalk ou factor, na qual salvar a imagem da heap toda é tão difícil quanto chamar um único método, você não tem que se preocupar com criar toneladas de Commands e transações com rollback são possíveis de ser criadas usando STM(Software Transactional Memory) ou simplesmente alguns become(). Outro problema é que criar buscas complexas com Java é um desastre, muito difícil de bater álgebra relacional ou simplesmente SQL nisso, nesse ponto linguagens funcionais dão um show no Java que beira a humilhação, aplicar predicados e transformações sobre coleções, criando e processando tuplas é super simples, é arroz-com-feijão.

No geral, eu vejo o prevayler com um brinquedo educacional para se aprender sobre serialização e só, usar profissionalmente não é interessante do aspecto que vai significar muito provavelmente trabalhar em projetos desintessantes ou mentalmente castrantes. Klaus e companhia que me desculpem, mas esse tipo de problema eu passo adiante, prefiro ficar com os mais divertidos e interessantes.

O maior argumento contra utilizar arquivos de configuração nunca foi muito o formato, seja xml ou qualquer outro, mas sim a quantidade abusiva de informação necessária para satisfazer o framework. Convenhamos, boa parte do tempo vamos usar apenas um conjunto pequeno dos recursos oferecidos e de uma maneira comum. Essas funcionalidades e interações recorrentes, devem possuir uma notação mais sucinta – o configuração deve ser ser otimizada para o uso comum. Para esse comportamento temos por uso de valores padrão inteligentes.

Porem, pode ser feito ainda mais. Neste caso, o framework assume que uma série de interações e padrões de uso serão utilizados e o usuário apenas configura aquilo que for diferente. Por esta maneira de trabalho, temos aquilo que chamamos por configuração por convenção. Juntando com valores padrão inteligentes, configuração deixa de ser uma preocupação, um martírio, para ser apenas um detalhe do projeto – que é seu devido lugar.

Em um cenário como esse, existe valor em expor uma extensa camada programática de acesso à configuração? Pelo resultado encontrado em vários projetos, sim, definitivamente existe, mas longe de ser uma boa ferramenta para substituir os arquivos. Primeiro, acho importante definir quais tipos de configuração existe em um framework e como isso afeta o valor ao abrir as portas para demais programadores.

Temos a Configuração de Inicialização, que pode ser vista como uma receita de bolo, que depois de utilizada, é descartada. O Hibernate é um bom exemplo, a configuração informada é utilizada para construir a SessionFactory e depois jogada fora. Outra forma de configuração é o Repositório de Parâmetros, onde toda configuração é armazenada de maneira que possa ser consultada em tempo de execução, o exemplo aqui fica por conta do Struts2, que transforma toda sua configuração em um modelo de objetos que representam os elementos envolvidos no processamento de uma requisição.

Das utilidades para configuração programática, destaco transformação, pois é aplicável no caso de Configuração de Inicialização. Transformação, como o nome sugere, altera a configuração já existente em algo mais útil, como colocar todas collections com lazy-loading; ou a partir de dados externos cria novos elementos, por exemplo, mapeando automaticamente todo um pacote de classes.

Quando existe um repositório, as possibilidades são maiores, o mecanismo de transformação pode ser aplicado na inicialização ou durante a execução. Para estender o comportamento do repositório utilizasse normalmente o padrão de projeto Plugin, para a descoberta do interessado, caso sejam muito, utiliza-se Chain-of-Responsibility para coordenar as transformações. O Struts2 funciona desta forma, é possível contribuir plugins que são responsáveis por instanciar as actions ou recuperar o mapeamento de um path. É possivel, por exemplo, descobrir quais actions existem no sistema e criar o mapeamento automaticamente.

Configuração programática é muito útil, porém não deixa de ser apenas uma ferramenta e, como tal, não deve ser o principal valor que um framework tem a oferecer, pois, a rigor, não trata do problema proposto a ser resolvido. Um framework MVC, por exemplo, deve ter como valores auxiliar no desenvolvimento de sites, dos quais configuração não é uma benéfice, mas sim um ardor maior ou menor para seu usuário.

Antes de tudo, tenho que concordar com este post do Phillip que DSLs são a bola da vez, e todos tem seus olhos virados para ver se rende alguma coisa. Mas o problema hoje não é a falta de ferramentas e sim a um bom playground para experimentarmos com o assunto. Construir, customizar e transformar linguagens não é nada facil e essa é a grande barreira para começarmos a ver avanços.

Mas voltando ao embrólio de como se apresenta o assunto ao grande público. Todos estão falando o tempo todo sobre como configuração é um problema a ser resolvido por linguagens de domínio. Até o Martin Fowler comete essa gafe em sua palestra na JAOO 2006! O problema é o mesmo que logging, eu diria, representa nenhum risco a complexidade de um projeto. Quantos realmente já tiveram problemas relacionados a dificuldade de colocar logging em uma aplicação? Configuração idem.

Além disso, acho que corremos na mesma direção do fiasco que foram as linguagens de quarta geração, as malditas 4GLs que tanto odiamos. Não vamos criar mini linguagens para o cliente poder sair customizando seu sistema, principalmente porque ele não saberia fazer isso de qualquer maneira. Criaremos atalhos para os desenvolvedores na forma de linguagens simples, limitadas e focadas em tarefas muito específicas; ou via customização da linguagem carro chefe do projeto.

DSLs como customizações é uma coisa que já vemos acontecer, via linguagens com suporte à macros (scheme, lisp, erlang*), ou com abuso do mecanismo de metaclasses – um exemplo, um pouco pobre, é RoR e ActiveRecord, que customiza Ruby para facilitar manipulação de banco, pobre pois poderia melhorar em muito a sintaxe em favor da manipulação de dados.

Enfim, acredito que veremos muito ainda sobre esse assunto, principalmente confusão e palestras que falam de configuração. Logo deveremos ter acesso a linguagens faceis de serem customizadas e que permitam muita experimentação no assunto. Foi essa experimentação que permitiu AOP ganhar momento com Java e ser assunto de piada entre C++.

*erlang não ter macros propriamente ditas, mas suporte parser transformers que são capazes de fazer o mesmo trabalho.

Compartilhar dados é estupido, exponha o comportamento do seu sistema.
Isso mesmo, avisar os desenvolvedores da outra equipe para eles usarem alguns selects que sua equipe definiu para fazer a integração é uma idéia horrivel. Os dados são a parte menos expressiva e ao mesmo tempo a mais sensivel do sistema.

Todo sistema depois que cresce além do trivial embute muito valor semântico aos dados que existem no banco, se você integrar nesse nível todos vão precisar saber isso ao risco de fazer ou ver a coisa errada. Ainda para piorar, essa técnica vira uma barreira à evolução, você não pode alterar o schema e continuar com suas alterações até que todos sistemas relacionados sejam também atualizados. Moral da história, integração feita no banco de dados é como se em um casamento os noivos trocassem pedaços de víceras em vez de alianças.

Tudo bem, já disse que é ruim, mas como fazer isso então? Crie uma série de serviços que expoam a funcionalidade pública do seu sistema e deixe o resto por conta da criatividade das outras equipes, elas vão agradecer. Isso normalmente significa lançar mão de usar EJB, CORBA, RMI e, principalmente, Web Services. Esse uso de Web Services é o que eu classifico por SOA pragmático, aquele que existe por algum propósito justo, existe para avisar e mostrar ao mundo as coisas que seu sistema pode fazer, como ele se comporta.
As vezes é meio chocante ver que com todo esse marketing feito por todos vendedores empurrando SOA não teve o menor impacto positivo. A parte que sofre mais parece ser a que menos adota esse tipo de tecnologia. Mas enfim, espero que esse post tenha servido pelo menos para avisar do desastre anunciado que é compartilhar as entranhas do seu sistema com os demais.