Hespanha

JMS é uma API do Java para lidar com troca de mensagens em aplicações. Devido a popularização da integração de sistemas por meio de mensagens, seu uso tem aumentado muito nos últimos tempos, principalmente pelo fato de ser extremamente simples integrar dois sistemas usando JMS. Porém, neste post, pretendo falar de uma outra utilidade muito interessante de JMS, a qual adotamos no último projeto que participei e que deu um resultado muito positivo para o sistema aumentando significativamente a sua robustez.

Tinhamos o seguinte cenário:

“É tentado cobrar um determinado valor do cartão de crédito do cliente, caso a operadora retorne OK, ou seja, a compra foi executada com sucesso, deve ser chamada uma API aqui da empresa que autoriza o cliente a usar o nosso sistema”

Agora pense na seguinte situação: O cliente é cobrado, debita o valor do seu cartão de crédito, mas quando
a API de autorização é chamada, acontece um erro e o cliente não é liberado para usar o sistema. O que fazer neste caso? Rollback da transação??? ahmmmm…não existe rollback na operadora de cartão de crédito! Mas mesmo se tivesse, ao meu ver essa não seria a solução ideal, afinal de contas, você perderia uma “venda”.

É aí que entra JMS e o título do post: “Contendo falhas de forma elegante”.

Nós adotamos a seguinte solução para este caso: Quando a operadora cobra o cliente, não há mais como voltar atrás, então, até esse ponto é fluxo é sincrono e, a autorização se tornou um fluxo assincrono. Com isso, foi criada uma  fila JMS e o cliente é colocado nesta fila para ser autorizado. A grande vantagem disso é que, em caso de um problema, a API do JMS possui uma propriedade configurável que faz com que ele retente processar de tempos em tempos. Com isso, caso o sistema não consiga autorizar o cliente na primeira vez, ele vai tentar novamente após 30 minutos, até 10 tentativas. Tempo suficiente para, se for um problema de banco por exemplo, o problema ser corrigido.

Mas não acaba aí, no JMS existe um conceito chamado “fila morta”. Caso após as 10 tentativas, o sistema não consiga processar aquela tarefa, ela será enviada para está fila. No nosso sistema, foi criada uma monitoração nesta fila. Caso algum registro caia na famigerada “fila morta”, o sistema irá alarmar e uma equipe responsável entrará em ação para solucionar o problema e após isso, reprocessar o registro.

Com isso, é possível uma ação totalmente pró-ativa, evitando assim chamadas na “Central de Atendimento” de clientes que pagaram e não receberam autorização para acessar o sistema.

Na nossa experiência aqui na empresa, JMS tem se mostrado uma excelente solução, tanto pela sua facilidade de uso com o auxílio de um servidor de aplicação, como o Jboss por exemplo, como também pela elegância e robustez que ele prove no seu uso.

Recomendo a todos os programadores Java a se aprofundarem neste assunto!

Um abraço!

É preciso tomar cuidado quando você está usando uma enum como retorno de um Session Bean. Tanto o servidor quanto o cliente precisam estar sempre com a mesma versão da enum. Caso você altere a enum do lado do servidor, mas não mudar a versão que está no cliente, se por um acaso a constante que você adicionou no enum for a retornada pelo Session Bean, subirá uma exceção no cliente. Não existe nada parecido com o conceito de serialVersionUid com o uso de enums.

Por um lado, essa característica é boa, pois força o seu cliente a sempre estar com a mesma versão da que está rodando no servidor. Mas, por outro lado, as vezes você quer adicionar uma constante ao seu enum, que em nada interfirá na maioria dos sistemas que estão usando o seu. Por exemplo:

-Um determinado sistema trata retornos com status PAGO e NÂO_PAGO.

Você quer adicionar um novo status de ANALISE na sua enum. Em tese, esse status não interessa para o sistema descrito acima, então, caso ele receba esse status ele poderia simplesmente ignora-lo. Mas com enum isso não é possível. Ou seja, se você tem 50 sistemas usuários do seu, e quer adicionar um novo status que só interessa para um deles, você é obrigado a forçar os 50 sistemas a atualizarem a versão “client” que receberam do seu.

Vi pelas estatisticas do blog que bastante gente cai aqui pesquisando sobre como configurar o Datasource
no Jboss, por isso resolvi fazer esse post.

O primeiro ponto é que o site da Jboss tem uma documentação muito boa ensinando fazer essa configuração.
Segue o link: http://wiki.jboss.org/wiki/ConfigDataSources

Porém, uma dúvida que o pessoal costuma ter é quando usar <local-tx-datasource> e quando usar <xa-datasource>.

Bom, a principal diferença entre os dois é que o <xa-datasource> suporta transações distribuidas, ou seja, vamos supor que você tem um método que realiza mudanças em duas tabelas. Até ai tudo bem. Porém, estas tabelas estão
em banco de dados diferentes. É nessa situação que você precisa de um <xa-datasource>. Se der algum problema e você
precisar fazer rollback, você precisa fazer rollback nas duas bases de dados. Um XADataSource fornece essa
caracteristica ao seu sistema. Ele gerencia a sua transação que passa por vários bancos de dados.

Se sua aplicação lida apenas com um banco de dados em uma máquina, o que você precisa é simplesmente de um <local-tx-datasource>.

Então é isso.

[]’s

Tivemos uma grande dor de cabeça por causa de um problema com o banco de dados aqui na empresa. Por algum motivo, a equipe de DBAs precisou reiniciar um dos bancos de dados utilizado na nossa aplicação. Após isso, nossa aplicação não conseguiu mais se conectar com o banco de dados. Nosso sistema é uma aplicação EJB que roda sobre o JBoss, nós usamos o pool de conexões do próprio Jboss e nossos datasources são XA.

Após diversos testes, descobrimos que para que as conexões do pool sejam recuperadas é preciso adicionar o seguinte parâmetro nas configurações do datasource:

<valid-connection-checker-class-name>org.jboss.resource.adapter.jdbc.vendor.OracleValidConnectionChecker</valid-connection-checker-class-name></code>

<xa-datasource>
<jndi-name>NameDS</jndi-name>
<track-connection-by-tx/>
<isSameRM-override-value>false</isSameRM-override-value>
<xa-datasource-class>oracle.jdbc.xa.client.OracleXADataSource</xa-datasource-class>
<xa-datasource-property name="URL">jdbc:oracle:thin:@host:1521:SID</xa-datasource-property>
<xa-datasource-property name="User">user</xa-datasource-property>
<xa-datasource-property name="Password">password</xa-datasource-property>             <exception-sorter-class-name>org.jboss.resource.adapter.jdbc.vendor.OracleExceptionSorter</exception-sorter-class-name>
<no-tx-separate-pools/>
<max-pool-size>3</max-pool-size>
<valid-connection-checker-class-name>org.jboss.resource.adapter.jdbc.vendor.OracleValidConnectionChecker</valid-connection-checker-class-name></code></code>

</xa-datasource>