Então, falando em Java…

Ontem aconteceu a terceira edição do já tradicional e indispensável evento Falando em Java, organizado pela Caelum em São Paulo.

O evento, como tudo que a Caelum faz, foi muito bem organizado, num excelente espaço, com ótimos coffebreaks (eu perdi o do almoço, porque fui comer comida chinesa no Hong He. #fail) e boas pessoas. Afinal de contas, como disse o Sério Lopes e o Fábio Kung na abertura do evento, a Caelum são as pessoas.

O que achei das apresentações?

As duas apresentações do Jim Webber foram fantásticas, mostrando uma visão bem realista de SOA, ESB e outras buzzworlds do momento, e dando uma boa luz no caminho dos serviços baseados na Web, REST e microformatos. Com certeza foram palestras que me fizeram reafirmar uma antiga crença: Você aprende muito com seus erros; e mudar de opinião porque aprendeu um pouco mais sobre algo, não é demerido nenhum, muito pelo contrário, é sinal de amadurecimento. O Jim é um exemplo disso.

A palestra do Guilherme Silveira junto com o Felipe Sabella teve uma ótima dinâmica, muito bem entrosada e com conteúdo homeopaticamente dosado. Nota 10. Mas infelizmente, nem todas as duplas tiveram o mesmo entrosamento, o que em alguns momentos acabou prejudicando bastante a mensagem das apresentações. Uma pela.

Destaque para o Paulo Silveira que, como sempre, não deixou a peteca cair e salvou a palestra; para o Ricardo Nakamura, que cativou a galera de primeira com sua revelação de que dorme com o pijama do Jaspion; e para o Kung que sempre tira uma carta ou duas sinistraças da manga.

O Sérgio e o Guilherme Moreira, no entanto, a pesar de dominarem o assunto que apresentaram, me deixaram um tanto decepcionado, porque a palestra não me pareceu muito condizente com o tema proposto. Por outro lado, devem ter feito vibrar os hibernate buys.

E claro, hehehe, eu não podia deixar de citar o mico o imprevisto do cluster com JBoss não funcionar na apresentação deles. Não por culpa do JBoss, é lógico, porque todos sabemos que há várias empresas mundo afora que rodam JBoss em cluster.

Eu mesmo fui um dos que entrou na zueira, mesmo não tendo nada contra o JBoss. Muito pelo contrário, é um dos meus preferidos – talvez por ainda não ter tentado colocá-lo em cluster. rsrs

Fica aqui minha remissão. I’m sorry!

Ponto positivo também pras Caelets, muito discretas e distintas, bem distantes da vulgaridade que vemos em muitos eventos por ai. Gostei do bom senso.

Ah! Tem também uma novidade que vale a pena citar: Logo mais teremos o livro da Caelum de Arquitetura e Design de Software à luz da Plataforma Java, com prefácio do gujeiro velho de guerra, Phillip Calçado. Se não me engano, o lançamento será em novembro.

Bem, no mais, é isso. Se você quiser uma cobertura mais completa sobre o evento, dê uma lida nas minhas tuitadas. Eu ralei pra caramba pra tuitar o evento interinho, não vou digitar tudo outra vez. Dá uma forcinha, vai. Dá uma olhada lida lá. 🙂

Até a próxima!

Entrevista com Ola Bini: Ioke, JVM, .NET e mais!

Quem me conhece há algum tempo ou acompanha este meu blog, sabe que eu sou totalmente meio fissurado por linguagens de programação. Sempre estou dando uma olhada em uma aqui e outra ali. Lendo, fuçando…

Mas tem um cara que com certeza é ainda muito mais fissurado em linguagens de programação do que eu – e diferente de mim, manja pra caramba. Esse cara é o Ola Bini, membro do core team do JRuby, consultor da ThoughtWorks, escritor do livro JRuby on Rails, membro do expert group da JSR-292 e criador da linguagem Ioke.

Bem, como não podia deixar de ser, eu resolvi fazer uma pequena entrevista com ele sobre Ioke, linguagens para a JVM e a Microsoft CLR, e uma coisinha ou duas mais. Confira!

Ola Bini e nosso compatriota Fábio Akita
Ola Bini e o nosso patrício Fábio Akita (QCon 2008)

Fale-nos um pouco sobre sua paixão por linguagens de programação. Quando isto começou? O que mais te motivou?

Oh wow. Boa pergunta. Eu não sei quando isto começou. Em algum momento obscuro do passado – muito longe para me lembrar. =)

Eu comecei bem cedo, com Basic no Apple IIc. Fiz muito C e assembler na minha adolecencia, e então, aprendi C++, Java e Lisp.

Penso que minha atual facinação por linguagens começou quanto eu percebi como diferentes linguagens são e como muitas coisas ruins são usadas. Esta percepção levou algum tempo, mas ficou cada vez maior.

Eu comecei com a implementação de outra linguagem há 5-6 anos atrás.

Além de contribuir com o projeto JRuby, você também criou a linguagem Ioke do zero. O que você tem a dizer sobre a JVM com plataforma para outras linguagens (além da linguagem Java)?

Sim. Então, a JVM é uma excelente plataforma para linguagens. Você tem um JIT muito maduro no Hotspot. Você tem garbage collectors fantásticos; e você tem um monte de bibliotecas e ferramentas disponíveis. A parte ruim é que a JVM atualmente está muito amarrada a linguagens que se parecem com Java, no nível do bytecode. É possível contornar isto, e nós estamos trabalhando na JSR292 para dar suporte a invocações dinâmicas na JVM.

Mas atualmente a JVM ainda está um bocado ligada a linguagens como Java. Isto não é necessário a tudo (muitas das tecnologias Java começaram em Smalltalk e Strongtalk).

Você acredita que a linguagem Java está caminhando para se tornar em uma linguagem de infra-estrutura? (Uma linguagem para escrever linguagens e outros componentes críticos de infra-estrutura.)

Espero que sim. Java não é uma boa linguagem para escrever aplicações – ela é realmente muito baixo nível.

Sobre Ioke. O que levou você a começar o projeto desta linguagem? Onde você pensa chegar com ela? O que você planeja para o futuro de Ioke?

Basicamente, a ideia com Ioke é ver o quão expressiva você pode fazer uma linguagem; e isto é o que tenho feito. Isto tem dado características linguísticas bastante avançadas; você pode fazer coisas nela que muitas pessoas inicialmente tem problemas para entender – mas ela permite você escrever código bastante sucinto e legível, que capture suas intenções.

O que acontecerá exatamente no futuro está no ar. Tenho muitas idéias, mas nada concreto no momento.

Recentemente, você também portou a linguagem Ioke para a Microsoft CLR. O que te motivou a fazer isto? O que você pensa sobre a plataform Microsft .NET como plataforma host para novas linguagens?

Sim! Eu fiz isto porque não queria que Ioke fosse somente uma linguagem da JVM. Queria ver como a CLR funcionaria para implementa-la e queria amplicar um pouco a base de usuário. A plataforma .NET é mais ou menos tão boa quanto a JVM. Algumas coisas são piores, outras são melhores.

O que você recomenda a aqueles que gostariam de, como você, serem designers de linguagens para a JVM? Esta recomendação seria mais ou menos a mesma para a plataforma .NET?

Há duas coisas que você precisa fazer. A primeira é ter uma boa idéia de como diferentes linguagens funcionam. Você precisa aprender linguagens de diferentes paradigmas e tentar entender como elas podem ser implementadas. Então, você precisa começar a fazer. Esta é a parte mais importante.

Comece realmente a implementar e ver o que acontece.

Finalmente, sinta-se à vontade para dizer o que quiser sobre Ioke.

Ela é muito “louca”. Ela é expressiva. Ela é muito lenta.

Penso que esta coisa de expressividade vai ser importante no futuro – já que nós estamos fazendo coisas mais e mais avançadas. Texto não escala se não podemos ter uma abstração estrutural (1). Ioke permite isto.

(1) N.T.: O que o Ola Bini quis dizer é que “texto, por si só, não pode ir a um nível superior, não pode evoluir, crescer, se não pudermos ter uma abstração estrutural sobre ele”. 🙂

Ruby + Rails no mundo Real 2009: Como foi?

Ontem aconteceu aqui em São Paulo o primeiro evento do GURU-SP, com co-participação da Tempo Real Eventos. Eu estive por lá e vou dizer – sob a minha ótica, claro – como é que foi.

Preço

O preço foi bem razoável para quem comprou antecipadamente, R$ 69,00; mas um pouco carinho para quem comprou na hora, R$ 129,00.

Local

O local, em geral, foi bom. Perto do metrô, pra quem foi de condução; estacionamento a R$ 10,00, pra quem foi de carro; opções de almoço perto não faltaram; o auditório acomodou todo mundo; o ar condicionado estava na medida certa; e o coffe-break, apesar de bem simples, também atendeu. No entanto não havia WI-FI. Isso foi realmente decepcionante, porque evento de programação, sem WI-FI pra galera que levou note, é russo.

Palestras

As palestras, sinceramente, me decepcionaram um pouco. Achei que foram muito introdutórias, muito superficiais. O que salvou o dia dos mais experiêntes foi a palestra do Fábio Kung e a do Caffo. Mas, sei lá, talvez tenha sido a estratégia do evento.

O track foi o seguinte:

1. Vinícius Baggio Fuentes: Criando um Instant Messenger usando Rails

XMPP é uma de minha áreas de interesse, então, estava realmente interessado nessa palestra.

O conteúdo estava legal, eu gostei do formato como a palestra foi estruturada, no entanto, acho que o Vinícius estava um pouco inseguro; e isso acabou atrapalhou um pouco em alguns momentos.

2. Hugo Lima Borges: Ruby, Rails e empreendedorismo

Esse é um assunto que tem sido muito recorrente em eventos de Ruby on Rails,  o que, com toda certeza, é um ponto muito positivo. Eu não me lembro de ter visto este tema rolar em eventos de Java, por exemplo. Mas a palestra, em si, achei meio frustrante pela superficialidade como o assunto foi abordado.

(Aliás, Hugo, você já empreendeu seu próprio negócio? Se sim, queria trocar umas figurinhas com você.)

3. Marcelo Castellani: Ruby no desktop

Não era para ser “Integrando Ruby e Java para facilitar a vida”?

Achei legal os comparativos e as dicas de quais toolkits funcionam melhor em cada SO, mas acho que faltou uma porção caprichada de código ao vivo. Código só no slide é um pouco chato. O legal é ver o código no slide, mas rodando no terminal também. Fica a dica.

4. Rodrigo Franco: Outsorcing, ou como trabalhar para empresas gringas

Para quem não sabe, esse cara é o Caffo, fundador da lista Rails-BR, que além de ser veiaco de Rails, também é muito experiente no que se propos a palestrar. Ele trabalhar com outsourcing, se não estou enganado, desde 2004.

Sua palestra foi muito, muito, interessante e todo mundo ficou muito intere$$ado mesmo. 🙂

A grande dia foi: Quer ser um pinguim com colar de ouro? oDesk.

Mas para isso, antes de mais nada, tenha uma conta ativa no GitHub; um blog que apenas copia notícias de outras fontes, mas que fala do que você pensa e sabe; uma página de portifólio e depoimentos também vai muito bem (segundo o Caffo, é indisponsável).

5. Mauricio Leal: GlassFish on Rails: Escalabilidade e Confiabilidade

Tema interessantíssimo para mim, uma palestra que eu estava realmente ansioso para ver. Acho que foi a que mais me decepcionou.

O Mauricio tem uma boa desenvolvura como palestrante, domina a oratória, mas sua palestra foi mais marketing – a Sun apoia Ruby, Rails e Open Source! – do que uma palestra técnica sobre o GlassFish. Como o próprio Fábio Kung, convidado pelo Mauricio, disse: O GlassFish é muito bom, mas o modo que a Sun tem o vendido à comunidade Ruby tem sido bem desadequada.

6. Carlos Brando: Só imaturos não testam

O Carlos é um cara que fala bem, sabe se expressar e sua palestra foi legal. Foi mais voltada a iniciantes em testes, mas bem legal. Na minha opinião, da próxima vez ele poderia abordar tópicos mais avançados de testes, cenários mais elaborados, etc.

Mas no geral, a palestra foi boa. Rolou até um marketzinho do Remarkable.

7. Willian Molinari: O que é e como funciona o RubyLearning

O RubyLearning é um site bem legal mesmo, ótimo não só pra quem está começando, mas para quem já tem algum conhecimento. Mas uma mini palestra para falar dele, não sei, não achei muito legal não. Acho que um post do tipo FAQ no RubyInside e no GURU-SP seria um apoio muito mais eficiente ao ótimo trabalho que o pessoal do RubyLearning tem feito.

Não posso deixar de dizer que o Willian, apesar de parecer bem jovem, soube conduzir muito bem a apresentação.

8. Fábio Kung: Ruby, muito mais do que reflexivo!

Palestra excepcional. O Kung realmente é um ótimo palestrante – instrutor da Caelum, não podia ser diferente.

A palestra dele abordou temas high level de metaprogramação com Ruby. ParseTree, Flog, roodi, Heckle e Ruby2Ruby foram alguns dos mandraques que ele nos apresentou. Foi o momento hacker do dia.

Ah! Além das ferramentas apresentadas, como o Carlos Brando, ele também fez marketing do seu projeto Rfactor.

Conclusão

Valeu a pena participar do evento, trocar idéia com os camaradas e tudo mais. Apesar dos pontos negativos, o resultado final é que o evento foi legal; e os pontos negativos ficam como um toque, para que o próximo evento seja ainda melhor.

Nos vemos no próximo evento!

De 0 a 100 com JRuby on GlassFish

O objetivo deste post é guiar você em sua primeira viagem com JRuby on GlassFish, partindo do zero e terminando com uma pequena aplicação JRuby on Rails rodando num servidor de aplicações GlassFish.

A idéia aqui não é explanar muito profundamente os produtos e assuntos relacionados, mas proporcionar um começo rápido e deixar fontes de pesquisa onde você poderá se aprofundar à medida que desejar.

Por que trabalhar com essa combinação?

A maioria das pessoas que trabalham com desenvolvimento sério de aplicações corporativas, grandes portais e sistemas complexos, que precisam de integração eficiente com sistemas em alta ou baixa plataforma, sabem que a Plataforma Java é excelente para isso.

A linguagem Java, por sua vez, todos nós também sabemos que é um tanto verbosa, isto é verdade, mas ainda assim é muito poderosa; e a combinação desse poder somado à excelência da plataforma e às inumeras API’s, frameworks e ferramentas,  tem se mostrado ser uma ótima opção para implementar outras linguagens. E é aqui que começa a nossa história com JRuby on GlassFish.

  • JRuby é a combinação da beleza e pragmatismo incontestável da linguagem Ruby, com a robustez e credibilidade da consolidada plataforma Java.
  • GlassFish é um reconhecido servidor de aplicações Java EE, parrudão e totalmente compliant com a especificação Java EE 5.

Usar essa a combinação para prover aplicações Rails é sinônimo de:

  • Ambiente de produção maduro e parrudo
  • Deployment facilitado
  • Ferramentas de monitoramento e gerenciamento de aplicação
  • Transação, mensageria, segurança
  • Integração completamente transparente com qualquer código Java
  • … e muito mais!!!

E ai, está motivado a continuar com esse tutorial?

É fato que JRuby é uma implementação de Ruby muito poderosa, rápida, confiável, thread-safe, etc, etc, etc. Mas não acho que faça muito sentido usar JRuby se você não precisa de integração com código Java, seja de um software legado ou mesmo uma API xyz específica. Se este não é o seu caso, aconselho dar uma olhada na combinação Ruby Enterprise Edition + Passenger (a.k.a. mod_rails) da Phusion.

Mãos à obra!

Antes da primeira coisa a fazer, você precisa se certificar de que possui o requisito mínimo necessário para esse tutorial: Um Java SDK instalado em sua máquina. No meu caso, estou com a versão 1.6.0_07. O ideal é que você tenha ao menos a versão 1.5.0. Caso não tenha, você pode fazer o donwload da versão apropriada ao seu SO e instalar conforme as instruções do produto, ou usar seu gerenciador de pacotes favorito. Você decide!

A primeira coisa a fazer: Instalar o JRuby

1- Baixe aqui a versão do JRuby mais atual (eu estou com a 1.2.0RC2);

2- Descompacte ele no diretório onde você deseja manter sua instalação;

3- Defina as variáveis de ambiênte conforme o exemplo a seguir:

# JRUBY-HOME, CLASSPATH and PATH to JRuby 1.2.0RC2
JRUBY_HOME=/home/leandro/ruby/tools/jruby-1.2.0RC2
CLASSPATH=$JRUBY_HOME/lib/jruby.jar:$CLASSPATH
PATH=$JRUBY_HOME/bin:$PATH
export JRUBY_HOME CLASSPATH PATH

4- Veja se está tudo funcionando, digitando no terminal:

$ jruby --version

A saída deve ser algo mais ou menos assim:

jruby 1.2.0RC2 (ruby 1.8.6 patchlevel 287) (2009-03-06 rev 9369) [i386-java]

Se você teve uma saída semelhante a essa, ótimo, tudo parece estar funcionando perfeitamente. Hora de ir para o próximo passo.

A segunda coisa a fazer: Instalar as gem necessárias

Instalar as gems pode demorar um pouquinho, dependendo de o quaão boa é sua conexão de internet. Tenha paciência! 🙂

Bem, vamos lá. No terminal…

1- Instale a gem jruby-openssl:

$ jruby -S gem install jruby-openssl

Isso se faz necessário porque o JRuby não suporta o openssl padrão do Ruby. Um pequeno detalhe. 🙂

-S, pra que isso?

O parâmetro -S serve para dizer ao JRuby que você quer que ele use prioritariamente os scripts que estão em seu diretório bin; ou, em segundo caso, no PATH do sistema.

2- Instale o Rails:

$ jruby -S gem install rails --include-dependencies

Esse comando instalará a versão mais atual do Rails, que no caso deste tutorial é a 2.3.2.

3- Instale o adaptador JDBC:

$ jruby -S gem install activerecord-jdbc-adapter

Este adaptador é genérico e possibilita conectar qualquer banco de dados que suporte JDBC. No entanto, ele faz necessário que você configure uma ou duas coisinhas a mais. Mas como no nosso caso vamos tratalhar com MySQL, vamos instalar também o adaptador JDBC especifico para MySQL. (Aliás, assegure-se de ter MySQL 5 instalado.)

$ jruby -S gem install activerecord-jdbcmysql-adapter

4- Instale o GlassFish v3 GEM:

$ jruby -S gem install glassfish

Pronto! Todas as ferramentas necessárias já estão instaladas. Vamos para o próximo [e mais interessante passo].

A terceira coisa a fazer: Criar uma aplicação

Em seu diretório de trabalho, faça o seguinte:

1- Crie uma aplicação Rails:

$ jruby -S rails jogapp

Como somos todos aficcionados por siglas, mandamos uma aqui: jogapp – JRuby on GlassFish Application. 🙂

Atenção!

A partir daqui, entre no diretório da aplicação jogapp e execute todos os script neste diretório.

2- Configure o banco de dados development no arquivo config/database.yml:

adapter: jdbcmysql
database: jogapp_development
username: root
password: senhadoroot
hostname: localhost

Lembre-se: Estamos usando uma instalação de MySQL 5 local.

3- Crie um cadastro bizarrão básicão:

$ jruby -S script/generate scaffold contato nome:string telefone:string

4- No terminal do MySQL, criar o banco de dados de desenvolvimento:

mysql> create database jogapp_development;

5- Migrar o esquema de banco de dados [para o banco de desenvolvimento]:

$ jruby -S rake db:migrate

Excelente! Tudo está criado e devidamente configurado. Agora…

A quarta coisa a fazer: Rodar a aplicação

Essa é a parte mais dificil. Prepare-se!

$ jruby -S glassfish_rails

É isso. Aqui na minha máquina, que nem é tão parruda assim, em 1 segundo, o GlassFish está de pé.

Agora você já pode abri seu browser preferido – que certamente não é o IE – apontar para a URL http://localhost:3000 para ver sua aplicação rodando no JRuby on GlassFish.

Dificil, não? 🙂

Pra finalizar, a quinta e última coisa a fazer: Se divertir!

Basta acessar http://localhost:3000/contatos e mandar bala! 🙂

Espero que você tenha se divertido até aqui, porque eu tenho me divertido bastante mesmo com essa combinação explosiva.

Como você pôde ver nesse tutorial, não há segredo. É muito trivial colocar uma aplicação para todar no GlassFish. É claro que eu também não mostrei nada de mais, além de usar um adaptado JDBC para tirar proveito dessa  ferramenta lapidadíssima e largamente usada no mercado. Vamos ver se logo, logo, eu escrevo um outro artigo mostrando um truque ou dois bem legal de integração com aplicações Java legadas (EJB, por exemplo).

É isso ai. Comentários são bem-vindos!

Sparrow, um cliente JMS baseado em JRuby

Mês passado comecei a tocar um projeto na CVC Turismo que, entre outras coisas, envolve troca mensagens assíncronas usando JMS. Esse trabalho foi está sendo tão divertido que me inspirou a escrever um post sobre Message-Driven Beans e Transações; e mais recentemente, a começar um novo projeto pessoal.

Sparrow é um cliente JMS implementado sobre JRuby e distribuido como uma Rubygem – hospedada no Github,  é claro. Ele é uma boa opção para quem precisa integrar sistemas Ruby com servidores de aplicações Java EE, provedores de mensageria JMS.

É pá, pum! Quer ver?

require 'rubygems'
require 'sparrow'

# Configuração que tem que ser feita uma única vez
jms_client = Sparrow::JMS::Connection::Client.new do |props|
  props.client_jar_file         = '/oc4j_extended_101330/j2ee/home/oc4jclient.jar'
  props.initial_context_factory = 'oracle.j2ee.naming.ApplicationClientInitialContextFactory'
  props.provider_url            = 'ormi://localhost:23791'
  props.security_principal      = 'oc4jadmin'
  props.security_credentials    = 'welcome'
end

jms_client.enable_connection_factories(
    :queue_connection_factory => 'jms/MyQueueCF'
  )

jms_client.enable_queues(
    :my_queue => 'jms/MyQueue'
  )

# Envio
jms_client.queue_sender(:my_queue).send_text_message('sparrow rocks!') do |msg|
  msg.set_string_property('recipient', 'sparrow-example')
end

# Recebimento
jms_client.queue_receiver(:my_queue).receive_message(
    :timeout  => 5000,
    :selector => "recipient = 'sparrow-example'"
  ) do |msg|

  puts msg.is_text_message?    # true
  puts msg.text                # sparrow rocks!
end

Fácil, não? 🙂

Se você quiser saber mais sobre o projeto, testá-lo, critica-lo, ou algo assim, por favor, não fique acanhado fique à vontade. E se não for pedir demais, deixe um comentário nesse post, como um feedback, para eu saber o quanto ainda preciso melhorá-lo e evoluí-lo.

Valeu!

Message-Driven Beans e Transações

Sexta-feira passada, postei  em meu twitter que estou tocando um projeto que envolve MOM. Hammm… JMS, para ser mais específico… rsrsrs…. Bem, o fato é que este projeto acabou me motivando a escrever este post sobre o assunto transação e EJB3 Message-Driven Beans (MDB),  apenas para fazer alguns lembretes e dar algumas dicas, já que este é um assunto fundamentalmente importante. Vamu que vamu então…

A primeira coisa importante a saber é que transações não são propagadas do produtor de mensagens JMS para o MDB que as consome, independentemente destes trabalharem com CMT ou BMT. Isso se dá pela própria natureza assíncrona de um sistema baseado em MOM, uma vez que uma mensagem pode levar horas para ser consumida, se assim fizer sentido ao sistema. Assim sendo, uma transação de um MDB está limitada ao escopo do método onMessage, que recebe e trata as mensagens.

A segunda coisa importante a saber é que quando o MDB faz o seu próprio gerenciamento de sua transação, a mensagem consumida não é parte transação. Ao passo que, se a transação do MDB for gerenciada pelo contêiner EJB, sim, a mensagem é parte da transação.

Sabendo essas duas coisas, somos levados a uma questão: O que acontece entãos se a transação falhar? Bem, está é a terceira coisa importante que precisamos saber. Sempre que o método onMessage completa sua execução sem erros, o contêiner EJB notifica ao provedor JMS reconhecendo o recebimento da mensagem. No entanto, se o correr uma RuntimeException durante a sua execução, o provedor JMS não receberá esta notificação de reconhecimento e, muito provavelmente, disponibilizará a mensagem para ser novamente consumida pelo MDB. Isso poderia causar um problema sério de loop infinito, em caso de poison messages, mas felizmente há antidoto para isso: Configurar o número máximo de tentativas de entrega de mensagens. Uff!!!

Como lidar então com exceções, rollback e reentrega de mensagens?

Há momentos em que a reentrega de mensagens é fundamental; e há momentos que não. Se ocorrer uma exceção de negócio, por exemplo, você não vai querer que a mensagem seja entregue novamente. Mas, se ocorrer um exceção por indisponibilidade de uma recurso (banco de dados, web service, etc), seria fundamental que a mensagem fosse entregue novamente, depois de algum tempo. Com isso em mente, vamos discutir um pouquinho o assunto.

Primeiro de tudo, não se esqueça que MDB’s não retornam exceções ao cliente que produziu a mensagem. Se a sua lógica de negócio em cima da mensagem produzida pelo cliente prevê uma exceção, pare e pense um pouco a respeito. Se você puder responder a ele com uma outra mensagem que ele (ou outro MDB responsável por notificar clientes) poderá consumir no provedor JMS, ótimo; caso contrario, esqueça, mensagens assíncronas não é uma opção para você.

Seguindo adiante com a solução, você precisa saber como MDB’s CMT ou BMT se comportam quando o assunto é transação. As diferenças básicas entre esses dois modelos de gerenciamento de transações são as seguintes:

Se seu MDB está baseado em CMT, significa que as mensagens que ele consume são parte da transação. Portanto, se a transação sofrer rollback, automaticamente, o consumo da mensagem também será revertido e o provedor JMS deverá tentar entregar a mensagem novamente.

Já, se seu MDB está baseado em BMT, significa que se a transação sofrer rollback o consumo da mensagem não será revertido, como acontece automaticamente no caso de CMT, e você poderá manter isso em segredo do provedor JMS, evitando que ele entregue a mensagem novamente. Ou, se fizer sentido ao seu requisito, você poderá notificá-lo do rollback de maneira bem simple e segura, basta lançar uma EJBException que é pá/pum.

Um pouco mais sobre Reconhecimento de Mensagem

A propriedade acknowlodgeMode, que determina o modo de reconhecimento da mensagem, pode ser definida como Auto-acknowledge ou Dups-ok-acknowledge. A primeria opção, instrui o contêiner EJB a notificar o reconhecimento da mensagem dentro do contexto da transação, seguindo as regras já citadas; e a segunda, o instrui a fazer isso num outro momento qualquer.

Essa propriedade pode ser ignorada, a menos que você esteja implementando um BMT ou um CMT com atributo de transação definido como NotSupported. Do contrario, o reconhecimento sempre ocontecerá no contexto da transação.

Se quiser saber mais, indico que você leia esse material.

Resumindo: Tome cuidado com suas exceções e não deixe que elas explodam sem mais nem menos, sem um tratamento adequado, nem nada, porque elas podem detonar suas transações e ainda causar problemas de negócio, com a reentrega de mensagens. Um bom log também vai muito bem, meu caro! 🙂

Bom, é isso ai… Espero que te ajude!

E se você ainda não leu esses dois posts: Cuidado com suas exceções e Transacionando EJB3 Session Beans, quando tiver um tempinho, leia. Talvez lhe sejam úteis também.

Até a próxima!

Pontapé inicial para aprender Erlang

Ano passado, no mês de outubro, resolvi começar a aprender Erlang – que é uma linguagem fantástica, digasse de passagem – e logo dei o pontapé inicial com material do próprio site da versão open-source da linguagem. Lá você encontra dois canais de conteúdos bem interessantes para o seu aprendizado.

O primeiro canal é o do famoso getting started, como estamos acontumados a encontrar em outras linguagens, só que em três versões diferentes, uma para cada saco gosto para leitura. Tem a versão rápida, a lenta, e a muito, muito, muito lenta. Já o segundo canal é uma coleção de diversas publicações interessantes, que vale a pena ao menos saber que existe.

Bom, com todo esse material disponível, seria chover no molhado eu querer dizer “o que é Erlang”, “qual o seu propósito”, e “blá blá blá”. Os materiais supra citado já fazem isso muito bem. 🙂

Em lugar disso, vou deixar aqui um passo a passo sucinto para instalar no Ubuntu a versão mais atual a partir dos fontes (já que não queremos a versão desatualizada disponível por apt-get) e mais alguns links para estudo rápido e mastigado. Ou seja, vou te dar um empurrãozinho te ajudar a dar o seu próprio pontapé inicial no aprendizado de Erlang.

Lembrando que, mesmo que você seja usuário de Windows, não há problema algum, este post também é pra você. Basta você fazer o download do .exe de instalação mais atual aqui e pular o próximo tópico.  E, caso você seja usuário de outra distro de Linux, I’m so sorry! Você vai ter que procurar sua própria receita de instalação no Google. 🙂

Instalação no Ubuntu

Antes de começar a instalação, você precisará fazer duas coisas:

1) Criar o diretório onde você fará a instalação

No meu caso, o path que é:


/home/leandro/Desenvolvimento/erlang/tools/otp_r12b-5

Vou usá-lo em toda a receita, então, fique atento e não se esqueça substituir pelo seu próprio path.

2) Baixar a última versão dos fontes aqui e depois descompactá-la no diretório criado no passo anterior

Feito isso, ótimo! É hora de começar a instalação de verdade. Vamu qui vamu!

1) Instale o conjunto básico de ferrametas para fazer o build


sudo apt-get install build-essential libncurses5-dev m4

2) Instale um conjunto de ferrametas de SSL, caso você ainda não tenha


sudo apt-get install openssl libssl-dev

3) Execute a configuração do build


./configure

4) Faça o build!


make && sudo make install

Aguarde, aguarde, aguarde…

5) Configure o diretório bin no PATH do sistema

Com seu editor de texto preferido, edite o arquivo /etc/bash.bashrc e insira o bloco abaixo:


# Setting the ERLANG_HOME and PATH to Erlang otp_r12b-5
ERLANG_HOME=/home/leandro/Desenvolvimento/erlang/tools/otp_r12b-5
PATH=$ERLANG_HOME/bin:$PATH
export ERLANG_HOME PATH

Ou faça como você preferir, esse passo é bem a la vonté mesmo. 🙂

6) Teste!

No console, digite erl. Se carregar o Erlang (BEAM) emulator é porque está tudo OK!

Se não carregar o Erlang (BEAM) emulator, revise os passos anteriores com calma, para ver se você fez tudo certinho, se não errou ou se esqueceu de algum detalhe. Caso ainda tenha problemas, o Google é seu amigo!

Mais dicas de referências

Como disse, além dos links que citei no início que estão realmente repletos de material interessante, queria indicar também uma série de posts do Caio Ariede, que também está aprendendo a fantástica Erlang.

Outra dica é um projeto que criei no meu GitHub [que vergonhosamente não tinha nada desde outubro] para colocar os códigos dos meus estudos, mas até agora só subi uns poucos programinhas bem didáticos do Getting Started Lento. Vamos ver se logo arranjo um tempo para organizar a coisas por aqui e subir mais coisas legais. Fique de olho nele.

Mais uma, ainda no GitHub, é o projeto que o Nando Vieira criou para publicar suas anotações da leitura do livro Programming Erlang, Software for a concurrent world, de ninguém menos que Joe Armstrong.

E para finalizar, não deixe de ler meu post sobre programação funcional, se você quiser ter uma rápida introdução a esse assunto.

É isso ai, até mais!!!

Biblioteca Digital da UNICAMP pra quem quiser ver

Não sei há quanto tempo a Biblioteca Digital da UNICAMP está disponível na web pra quem quiser ver, mas só hoje descobri. (Alguém sabe me dizer o quanto estou atrasado em minha descoberta?)

Há muito material interessante, em diversas áreas de conhecimento. No tópico de teses, por exemplo, há mais de 25 mil trabalhos, de 20 institutos diferentes. De artes a química, passando por engenharia de alimentos e computação, você encontra de tudo.

Espero que seja útil pra você também. 🙂

Tem gente que acredita em cada coisa

Não é de hoje que esbarramos aqui e ali com artigos em blogs e revistas trazendo revelações – que mais parecem vindas do além – sobre verdades e mentiras no desenvolvimento de software.

Esse capitulo está presente desde sempre. Quem é que não conhece pelo menos uma ou duas, aham?

Há alguns anos:

“Java é lento!”

Há alguns meses:

“Ruby é lento e Rails não escala!”

Isso só pra citar duas das pérolas da velocidade (em nosso tempo).

Hoje mesmo li um post que reune e desbanca algumas dessas revelações – do além -, que algum “guru” do desenvolvimento de software proferiu e acabou caindo na graça do povo. Risada na certa. Vale a pena ler, mesmo que você já conheça todas. 🙂

E você, quais são as verdades e mentiras do desenvolvimento de software que você acha mais engraçadas, descaradas e descabíveis?

Web services RESTful em Java com Jersey

Estou estudando hoje a JSR 311 e sua implementação de referência, o projeto Jersey, por conta de um requisito arquitetural que surgiu em meu novo projeto aqui na CVC Turismo. Trata-se da integração de várias aplicações legadas, desenvolvidas com tecnologias completamente heterogêneas – Java, ASP e PL/SQL Web Toolkit.

Estamos, eu e meus colegas da equipe de arquitetura, considerando bastante o uso de web services REST. Por isso meu interesse pelo Jersey, uma vez que a plataforma base desse projeto é Java.

Para aqueles que se interessam pelo assunto, tempos atrás gastei investi um tempo lendo o material produzido pelo Bruno Pereira, o qual considero a melhor referência de REST em lingua portuguesa. (Jabá!!!)

Hoje resolvi ler também um de seus artigos produzidos para a revista Java Magazine – que IMHO não é lá uma ótima revista de Java, mas que volta e meia publica um ou dois artigos interessantes -, para refrescar a memória.

Taí! Para quem quer ter um primeiro contato com Jersey e a JSR 311, ficam aqui as dicas.