Não gosto de configuração programática

Não queria escrever sobre nada fora do meu foco atual mas estou com um assunto engasgado que preciso colocar minha opinião pelo menos para marcar presença. Sei que muitos amigos detestam o monte de XML que precisam escrever para configurar os frameworks que usam e entendo porque não gostam de XML.

Fui um dos primeiros entusiastas na adoção de XML na integração de sistemas ainda quando trabalhava com EDI em 2000. O uso de XML tem um monte de vantagens e algumas poucas, porém quase fatais, desvantagens. Só vou falar de algumas desvantagens: violam TDD, são difíceis de localizar erros, acarretam lentidão quando usadas com parsers inadequados e principalmente ser fácil de abusar do seu uso.

Tendo em vista as desvantagens, alguns programadores resolveram expurgar o XML das suas configurações e passaram a fazer a chamada configuração programática.

Entendo por configuração aqueles parâmetros que servem apenas para permitir a instalação e ajuste fino das aplicações em diversos ambientes. Lá devem ficar as informações que podem ser alteradas pelos profissionais de suporte.

Porém nos últimos tempos há um claro abuso deste conceito. Houve uma febre para tornar os sistemas flexíveis e customizáveis. Os arquivos de configuração cresceram muito. Alguns contêm informações que só dizem respeito ao desenvolvedor do sistema e nunca deveriam estar expostos como configuração. Os arquivos enormes ficaram tão difíceis de alterar que as empresas precisam dispor de programadores especialistas nos frameworks que nada mais fazem do que gerenciar as configurações (Inner-Platform Effect). Ficou mais complexo configurar um sistema do que usar os 237 botões do controle remoto do seu home theater.

1. Solução natural do problema:

• Configurar por convenção onde se pode saber por experiência onde estão as coisas.
  
• Permitir mudanças nas convenções por convenção de forma centralizada para fazer uma vez só na vida com alterações em um único lugar.
  
• Limitar as configurações somente àquilo que um profissional de suporte pode fazer em poucos minutos para apagar um "incêndio".
  
• Configurações que só dizem respeito aos programadores preferencialmente devem ser feitas com anotações. É claro que respeitando as limitações e imposições dos frameworks de IoC, AOP, etc..
  

2. Solução adotada pelos defensores de configuração programática

• Configurar via programação Java

Talvez eu esteja ficando um velho ranzinza mas acho absurdo trocar um configuration manager por outro programador e obrigar que todas as modificações sejam feitas em ambientes de desenvolvimento com Java instalado mais toda a parafernália de IDE, dependências, etc. Para mim a solução de configuração programática apenas engessa os sistemas e não toca no real problema de excesso de customização para gente que não precisa disto.

Aplicações corporativas nunca funcionam isoladas. Mensagens síncronas x mensagens assíncronas

Nas empresas há dezenas de sistemas que precisam trocar informações. Estes sistemas, algumas vezes, foram desenvolvidos de forma independente visando resolver algum problema isolado. Sendo assim ou não, quase todos precisam se integrar aos demais, trocando informações e serviços.

Muitos programadores desenvolvem as trocas de mensagens e as chamadas a comandos em outros sistemas usando mensagens síncronas. Isto geralmente exige algum esforço de programação para ter garantias de que as mensagens chegam ao destino. Talvez a maior parte das aplicações que usam web services para integrar aplicações o façam trocando mensagens síncronas.

Este post serve apenas para lembrar que há vantagens na integração de sistemas usando troca de mensagens assíncronas que usa a abordagem "envie e esqueça": Quem envia as mensagens ou pedidos de execução de comandos não precisa ficar parado esperando a resposta. Esta pode vir posteriormente e ser recebida via callback por alguma thread que a escute. As principais vantagens são:

1. As mensagens ou chamadas a comando podem ser retransmitidas e assim a confiabilidade global do sistema aumenta muito.
2. Por não precisar ficar bloqueado esperando resposta, melhora o uso dos recursos dos sistemas e assim também a escalabilidade.

Usar mensagens assíncronas não é mais difícil nem mais caro. Apenas exige que se inclua na arquitetura um provedor de serviços de mensageria. Para a nossa sorte há vários provedores gratuitos com bom desempenho com boas facilidades de gerenciamento.

Em termos de programação Java o esforço não aumenta muito por 2 motivos:

1. A API JMS é boa, estável e fácil de programar mesmo sem auxílio de Message Driven Beans;
2. A parte "suja" da programação para garantir o recebimento das mensagens fica por conta do provedor de mensageria.

Então o que você está esperando para mudar seus paradigmas e diminuir o acoplamento entre seus sistemas? Se é por falta de livros seus problemas acabaram pois aí vão 2 dicas boas:

1. Java Messaging do Eric Bruno
2. Enterprise Integration Patterns de Gregor Hohpe e Bobby Woolf com várias contribuições de outros.

Pois é, comecei. Alia jacta est

Será que conseguirei tempo para escrever alguma coisa por aqui? Sei lá, vou tentar.

Meu interesse atual é CEP/ESP/EDA, isto é, sistemas movidos por eventos. Quais são estes sistemas? Quase todos os sistemas corporativos que trocam mensagens dependem de eventos ou usam regras baseadas em fluxos de eventos para tomada de decisões.

Já que falei em trocas de mensagens, é claro que JMS, ESB, SOA e Web Services também fazem parte dos meus interesses e talvez escreva sobre isto. Se possível usando o Apache Camel para modelar as mensagens como tenho feito em brincadeiras caseiras.

Finalmente há 2 assuntos, que se sobrar tempo, pretendo abordar, pois são antigos interesses meus: aplicações servidoras e JMX, sendo este último assunto uma das jóias raras do Java.

Ah, e porque windshifts que significa rondadas de vento? Como antigo velejador, espero que as rondadas de vento me sejam favoráveis e me dêem motivação para escrever.

É isso aí, jogo feito, as cartas estão na mesa.