Mas como migramos toda a suíte para rodar sobre o SQL Server, configurei tudo para apontar para o banco de dados do WSO2 Governance Registry (arquivo conf/registry.xml) e do WSO2 Identity Server (arquivo conf/user-mgt.xml) - maiores explicações ficam para uma outra oportunidade.

Só que ainda ficou uma dúvida no ar! Aonde estavam as configurações de conexão de banco de dados que armazenam as informações do BAM propriamente dito? Pesquisando nos arquivos instalados encontrei um diretório "bam", e para minha não-surpresa, lá estavam mais dois diretórios:

• ./bam/database/: diretório com arquivos da base de dados do H2;
• ./bam/sql/: scripts de criação da base de dados em diferentes bancos (H2, SQL Server, MySQL e Oracle).

Com essa descoberta, o jeito foi partir para o básico, buscar um arquivo de configuração que pudesse conter a conexão apontando para esses arquivos.

leonardo@mcorp:~/Applications/wso2/wso2bam-1.0.1$ grep -r h2:database *
conf/registry.xml:        jdbc:h2:database/WSO2CARBON_DB
conf/user-mgt.xml:		jdbc:h2:database/WSO2CARBON_DB

Ops, não encontrei nada. Nova tentativa:

leonardo@mcorp:~/Applications/wso2/wso2bam-1.0.1$ grep -r h2 *
[milhões de respostas - ocultadas por mim - que não ajudam em nada]

Vamos lá, filtrar um pouco mais para quem sabe ser mais feliz:

leonardo@mcorp:~/Applications/wso2/wso2bam-1.0.1$ grep -r jdbc:h2 *
conf/registry.xml:        jdbc:h2:database/WSO2CARBON_DB
conf/user-mgt.xml:		jdbc:h2:database/WSO2CARBON_DB
repository/dataservices/BAMSummaryGenerationDS.dbs:jdbc:h2:bam/database/WSO2BAM_DB
repository/dataservices/BAMConfigurationDS.dbs:jdbc:h2:bam/database/WSO2BAM_DB
repository/dataservices/BAMStatQueryDS.dbs:jdbc:h2:bam/database/WSO2BAM_DB
repository/dataservices/BAMDataCollectionDS.dbs:jdbc:h2:bam/database/WSO2BAM_DB
repository/dataservices/BAMSummaryQueryDS.dbs:jdbc:h2:bam/database/WSO2BAM_DB

E agora sim! Com isso descobrimos que ele utiliza alguns data services que realizam o trabalho "sujo".

Então, basta alterarmos todos esses serviços para conectarem na base de dados criada no SQL Server (dentro de cada serviço tem exemplos). Os serviços são:

• repository/dataservices/BAMSummaryGenerationDS.dbs
• repository/dataservices/BAMConfigurationDS.dbs
• repository/dataservices/BAMStatQueryDS.dbs
• repository/dataservices/BAMDataCollectionDS.dbs
• repository/dataservices/BAMSummaryQueryDS.dbs

E carregar o arquivo bam/sql/bam_schema_mssql.sql na base de dados e... voilà.

INFO -  Server  :  WSO2 Business Activity Monitor-1.0.1
INFO -  WSO2 Carbon started in 6 sec

Os estudos sobre o WSO2 Business Activity Monitoring continuarão num próximo capítulo, sempre acompanhado de dicas e descobertas. (:

Posts relacionados

• Novidades nos lançamentos (nov/2009) da plataforma WSO2
• Lançamento do WSO2 Stratos (alpha)
• Utilizando o Array Type do WSO2 Data Services Server 2.5.x
• Compilando o plugin do WSO2 Data Services Server para o Eclipse
• WSO2 e a quinta-feira agitada: muitos lançamentos

Esse preço pode ser na maioria das vezes inviável para empresas de menor porte, sobrando apenas as soluções de menor porte (e preço) e as opções livres. E aí sobra pra quem "inventou" a moda, afinal, "quem inventa aguenta".

Dois anos atrás, quando começamos os estudos para implementação de SOA aqui no trabalho, apanhamos - e muito - com esse problema. Tínhamos que implantar toda a arquitetura escolhida de maneira barata (entenda: de graça).

Achamos muitas opções que prometiam resolver os problemas, mas que no fim trazia "N" dificuldades na implementação, desenvolvimento e/ou até instalação. Tudo parecia meio cru e o que diziam ser as melhores, não passavam de um serviço e um milhão de arquivos (em sua maioria XML) para serem editados quase que totalmente manual.

Alguns dos problemas que enfrentamos na maioria das soluções foram:

• Documentação: se não fosse nula, era fraca e muito pouco clara;
• Desenvolvimento: o lançamento de novas versões e correções de bugs eram lentos (sem contar as frases do tipo "na versão Enterprise está resolvido");
• Comunidade: praticamente o mesmo problema da documentação, nula; e
• Código aberto: algumas ferramentas dizem "código aberto", porém abrem uma parte do código (que normalmente doam para a Apache Foundation) e o crucial não, impossibilitando corrigirmos ou descobrimos o que acontece.

A lista acima não diz tudo pelo que passamos e enfrentamos, é apenas um resumo. Então, após testar algumas ferramentas e utilizar algumas outras, optamos pelo WSO2, que apesar de não resolver todos nossos problemas, pelo menos chegou mais perto.

Vamos fazer uma comparação com os problemas listados e o que nos levou a escolhê-lo:

• Documentação: quando começamos era praticamente nula, mas como eles utilizam outros projetos livres (como: Apache Synapse, Apache Axis2, Apache Rampart e etc) sem maiores modificações, fica mais fácil achar documentação para o seu problema naquele projeto ou biblioteca e atualmente eles estão melhorando um pouco nisso escrevendo artigos e disponibilizando alguns webcasts grátis;
• Desenvolvimento: os lançamentos de versões está numa velocidade boa e rápida, apenas os bugs ainda peca um pouco, mas olhando o JIRA é possível achar vários patches, nos deixando ainda a opção de alterar o código, caso queira;
• Comunidade: é fraca como todos os outros, existe o fórum, mas é somente em inglês; e
• Código aberto: como dito antes, o código é aberto e você pode alterar a vontade, que pode ajudar na necessidade de resolução de bugs mais críticos.

Pode não ser a solução perfeita, mas foi o que mais nos deixou tranquilos para trabalhar. Alguns produtos ainda tem muito o que evoluir e alguns estão bem evoluídos, mas com muito a melhorar. Posso dizer que estamos bem com a opção que fizemos, mesmo que não tenhamos chego aos 100% de implantação da arquitetura que pensamos.

Posts relacionados

• SOA está para WSO2 ou WSO2 está para o SOA?
• Novidades nos lançamentos (nov/2009) da plataforma WSO2
• Compilando o WSO2 Carbon 3.0.0 e corrigindo o WSO2 Data Services Server 2.5.0
• Marília TechDay 2010
• WSO2 Business Activity Monitoring + SQL Server