CØdeZØne!

Há alguns meses perguntaram ao Rich Hickey:

“How much does a choice of language really matter? Are there good reasons to choose one language over another or does it all come down to taste?”

E sua resposta foi:

“I think it matters quite a bit. A good language is opinionated, and strives to make a particular style of programming easy and idiomatic. It only seems a matter of taste when you are comparing languages that are more similar than they are different, like Java/C# or Python/Ruby. Try something really different like Clojure, Haskell, or Erlang and the fact that it matters becomes readily apparent.”

Eu acho que concordo bastante com sua opinião. Discutir se Java é melhor do que C#, por exemplo, é inútil, porque as duas linguagens são muito semelhantes. Nesse caso, o que acaba pesando mais na hora da escolha é o ecosistema no qual cada linguagem está inserida, que pode agradar mais a um ou a outro programador. É puro gosto.

O mesmo vale para Ruby e Python, como ele mesmo cita.

Mundos diferentes

Mas e se a comparação for entre Java e Ruby, por exemplo, como é que fica? Na minha humilde opinião, fica no sense. Porque Java e Ruby não são liguagens de mesma proposta; e mesmo sendo ambas de propósito geral, ambas tem objetivos claramente diferentes.

Comparação entre mundos diferentes

Agora vou, propositalmente, contradizer um pouco o que eu disse à cima: faz sentido, sim, você comparar Ruby com Java; Erlang com Python; F# com PHP. Sim, faz sentido.

Faz sentido quando você está escolhendo a linguagem que oferece a melhor solução para um dado domínio de problema.

Super CRUD com Erlang? Não, acho que não.

Precisar de concorrência massiva, tolerância a falhas, processos distribuídos, downtime mínimo? Humm, não sei não, mas será que não é de Erlang que você precisa?

Entende? É nessa hora que a escolha de uma linguagem começa a pesar de verdade. Isso realmente importa.

Mundos diferentes se complementam

Tempos atrás, escrevendo programas Erlang/OTP, senti falta de uma ferramenta que me ajudasse a criar rapidamente a estrutura inicial do projeto e umas coisas mais. O que fiz? Criei uma ferramenta que faz isso: otp_kickoff. Em Erlang? Não, em Ruby. Fiz isso em poucas horas, usando Thor.

Pouco tempo depois, senti falta de uma ferramenta de build amigável. Novamente, o que fiz? Criei o ebuilder, usando Ruby/Thor.

Um outro exemplo de mundos diferentes que se complementam é o JSparrow, um cliente de JMS bem fluente, que fiz usando JRuby.

Essa é a ideia de tirar o melhor de cada linguagem!

Mesmo porque, dificilmente, você constroi um sistema de verdade – que não seja um super CRUD – com apenas uma única linguagem de programação. Na minha equipe mesmo, há sistemas desenvolvidos em C# .NET, que são buildados, testados e deployados com Ruby/Rake/Cucumber e usam Java/Ivy como repositório de assemblies. Isso sem falar em JavaScript, que também tem de monte.

Esse é o mundo real dos sistemas de verdade.

Moral da história

Isso me faz pensar que brigas de fanboys de linguagens – em frenéticas buscas por prosélitos – são uma verdadeira piada.

Fazia tempo que estava para blogar algo sobre como é fácil fazer programação distribuída com Erlang. Derrepente, hoje, acabei perdendo o sono e eis aqui o post.

O mais simples do mundo

Pra começar, vamos ver o exemplo mais simples de computação distribuída que se pode fazer e aprender alguma coisa com ele. Ele é como um simples chat. Pois muito bem, vejamos!

Fazendo o setup

No terminal, inicie um Eshell com o seguinte comando:

$ erl -sname jose

E num outro terminal, inicie outro Eshell com:

$ erl -sname maria

Agora vá no primeiro terminal, no Eshell do José, e execute o seguinte comando:

(jose@codezone)1> register(console_jose, self()).

E no segundo terminal, no Eshell da Maria, faça o mesmo:

(maria@codezone)1> register(console_maria, self()).

Tudo bem, setup feito, hora do bate-papo!

Jogando conversa fora

“Ei José, diga oi…”

(jose@codezone)2> {console_maria, 'maria@codezone'} ! "Oi Maria, tudo bem?".

Veja o terminal da Maria. O que aconteceu? Nada? A mensagem não chegou? Chegou, chegou sim. Vejamos:

(maria@codezone)2> regs().

Na primeira coluna, procure pelo processo console_maria. Achou? Agora veja na última coluna desse processo. Que número tem aí? 1? Pois é, isso nos indica uma coisa. Ainda nesse Eshell, execute o seguinte comando:

(maria@codezone)3> flush().

Opa! E agora? Shell got “Oi Maria, tudo bem?”, certo? Taí a mensagem que a Maria recebeu do José.

Agora, que tal a Maria ser gentil com o José e responde-lo cordialmente?

(maria@codezone)4> {console_jose, 'jose@codezone'} ! "Vou bem, e voce?".

Se você quiser, pode ver o registro de processos no Eshell do José, como fez anteriormente com o da Maria. Ou pode simplesmente:

(jose@codezone)3> flush().

E receber a mensagem Shell got “Vou bem, e voce?”.

Entendendo tudo isso

Por sorte, não há muito o que explicar até aqui – já que fizemos o exemplo mais simples do mundo. Uff!

Que tal começar do começo? Vamos entender os passos de setup?

1- A primeira coisa que fizemos foi iniciar dois Eshell que, na verdade, tornaram-se dois nós do nosso cluster de runtimes Erlang.

Todas as vezes que você inicia um Eshell com a flag -sname, o que você está fazendo é criar um nó de runtime Erlang na sua rede. Na verdade, isso pode ser feito também com a flag -name.

Qual a diferença entre elas?

-sname cria o nó e dá a ele um “short name”: nome_do_no@host;
-name, pelo contrário, cria o nó dá a ele um “long name”: nome_do_no@ip_address ou nome_do_no@host.local, no caso de rede local.

Você pode perfeitamente iniciar diversos nós em uma mesma máquina, como fizemos a pouco. No entanto, você não pode duplicar os nomes dos nós, uma vez que estes são usados para identificá-los no cluster e torná-los comunicáveis uns com os outros.

“Lembrando que o nome dos nós são sempre sufixados pelo nome/ip do host, não há problema algum em ter o mesmo nome de nó em máquinas diferentes.”

Uma outra coisa interessante de aprender aqui é como os nós se comunicam. Toda comunicação entre nós é feita por um daemon chamado epmd. Este programa faz parte do sistema de runtime Erlang e tem um papel fundamental em sua arquitetura de clusters, porque sempre que “o primeiro nó” é iniciado numa máquina, automaticamente, ele também é iniciado, caso ainda não tenha sido, e passa a escutar mensagens na porta 4369 e rotea-las para o nó apropriado.

“Independente de quantos nós estejam rodando numa máquina, sempre haverá apenas uma instância do epmd rodando.”

Por fim, ainda sobre o setup dos nós do cluster, há uma outra flag que não demonstrei no exemplo acima, mas que é bem interessante e você depois pode pesquisar a respeito.

-setcookie define um “secret cookie” que serve como um tipo de token para autenticar a comunicação entre os nós do cluster. Isso quer dizer que, somente os nós iniciados com um mesmo cookie podem se comunicar. Por outro lado, sempre que um nó é iniciado sem especificar um cookie, o runtime Erlang toma a liberdade de cria um e gravar no arquivo ~/.erlang.cookie. Nestes casos, todos os nós não iniciados com um cookie compartilharão o mesmo cookie guardado nesse arquivo.

No caso do nosso exemplo ultra simples, um cookie poderia ser usado para criar uma sala de bate-papo, onde: se um nós é iniciado informando um cookie, ele entra na sala equivalente; no entanto, quando não informado, vai para uma sala genérica.

Interessante? Pois é… E esse assunto acaba puxando o da flag -hidden, que você pode aproveitar e pesquisar também.

2- A segunda coisa que fizemos no setup foi registrar um processo alvo de nossas mensagens.

Como a idéia aqui é explicar – um pouco, porque ainda há uma porção de coisas que poderiam ser faladas, mas isso deixaria esse post imenso! Dê uma olhada na documentação oficial – como funciona a arquitetura de cluster de runtimes Erlang e mostrar como este provê uma maneira simples de programação distribuída, preferi não escrever um programa de chat, mas apenas usar o próprio Eshell para isso.

Com este pré-requisito em mente, o que fiz foi apenas registrar o próprio processo do Eshell – usando self(), que você entende como funciona – com um nome especifico em cada nó do cluster (console_jose para um e console_maria em o outro) para fazer a troca de mensagens entre eles.

E o bate-papo, como é que rolou?

Essa é a parte mais fácil da coisa, na minha opinião. Se você já lidou com processos em Erlang, vai tirar de letra.

1- Trocamos mensagens entre os dois processos de maneira bem semelhante ao que fazemos normalmente com processos contidos num único runtime.

A única diferença aqui é que, em vez de simplesmente codarmos algo como console_jose ! “Show de bola”, codamos {console_jose, ‘jose@codezone’} ! “Show de bola”. Ou seja, além no nome do processo, informamos também em que nó do cluster ele está, tudo em uma tupla.

Um exercício legal de você fazer é o seguinte…

a. No Eshell da Maria execute:

(maria@codezone)5> console_maria ! "Show de bola".
(maria@codezone)6> flush().

b. Depois, ainda no Eshell dela, execute:

(maria@codezone)7> console_jose ! "Show de bola".

O que aconteceu? Na primeira execução, o Eshell da Maria recebeu uma mensagem, correto? Mas na segunda execução, o Eshell “crasheou”. Por quê? Porque ele não reconheceu o átomo console_jose como sendo o nome de um processo, uma vez que o processo registrado como console_jose está em outro nó do cluster. Aliás, como o Eshell da Maria crasheou, se você tentar enviar mensagens a ele novamente, como fez anteriormente e havia funcionado, ele vai crashear novamente, porque a referência ao processo que havia sido registrada tornou-se inválida.

Você precisa ficar muito atento a isso, porque quando você manda um mensagem para um processo que está em outro nó, mesmo que ele não exista, você não receberá erro – exatamente como acontece com envio de mensagens pra processos locais inexistentes.

Quer ver? Faça o seguinte teste:

(maria@codezone)8> {console_jose_123, 'jose_abc@codezone_xyz'} ! "Nao vai crashear".

E agora, o que aconteceu? Nada!

2- Outra coisa que fizemos foi usar os truques de flush() e regs(), mas esses já são bem conhecidos.

Se você costuma usar o Eshell, com certeza, já deve ter usado flush() e regs(). Caso ainda não tenha usado, aqui vai um resumo:

- flush() descarrega as mensagens contidas na caixa postal do Eshell (que como você sabe, nada mais é do que um processo Erlang qualquer);
- regs() lista os processos registrados do runtime em execução.

Só o gostinho

Como disse em algum canto nesse post, ainda há bastante o que falar sobre programação distribuída com Erlang. Só pra variar, esse post foi só pra dar o gostinho. Ainda há muito mais!

Bem, quem sabe qualquer dia desses não perco o sono novamente e escrevo um pouco mais sobre o assunto. Quem sabe?

Ao ler o título deste post, talvez você esteja se perguntando: por que eu deveria considerar Erlang para meu próximo grande projeto? Bem, meu objetivo com este post é te apresentar alguns importantes motivos para fazer isto.

Erlang nasceu no laboratório de ciência da computação da Ericsson na década de 1980, influenciada por linguagens como ML, Ada, Module, Prolog e Smalltalk, quando um time de três cientistas – entre eles, o grande Joe Armstrong – receberam a missão de descobrir qual seria a melhor linguagem de programação para escrever a próxima geração de sistemas de telecom. Após dois anos de investigação e prototipação, estes cientistas descobriram que nenhuma linguagem era completa o bastante para tal objetivo e, conclusivamente, decidiram criar uma nova linguagem. Nasceu então Erlang, the Ericsson Language.

De lá pra cá, Erlang tem sido evoluida e usada para escrever grandes sistemas críticos, porque é exatamente nesse cenário que Erlang faz mais sentido. Se seu projeto é construir um sistema crítico, altamente tolerante a falhas, com disponibilidade 24×7 e veloz como o papa-léguas, sim, Erlang é para você. Mas se não é bem esta sua necessidade, se você quer apenas construir um pequeno sistema, com baixa concorrência, poucos usuários, pouca necessidade de performance e possibilidade de passar horas down em manutenção, não, você não precisa de Erlang. Que tal Basic?

Diferente de algumas linguagens que nascem para encontrar um nicho, Erlang nasceu com um problema a ser resolvido, com requisitos a serem atendidos. Tolerância a falhas, concorrência realmente pesada, computação distribuída, atualização da aplicação sem derrubá-la, sistemas de tempo real, este é o nicho de Erlang; foi para isto que Erlang nasceu.

Quem usa Erlang atualmente?

Além da Ericsson, é lógico, há algumas outras grandes empresas e projetos usando Erlang, como por exemplo:

- Facebook, no backend de seu sistema de chat, lidando com 100 milhõs de usuários ativos;
- Delicious, que tem mais de 5 milhões de usuários e mais de 150 milhões de bookmarks;
- Amazon SimpleDB, o serviço de dados do seu poderoso EC2;
- Motorola, CouchDB, RabbitMQ, Ejabbed, etc.

Ok, mas Erlang é propriedade da Ericsson?

Não, felizmente, não. Em 1998 a Ericsson tornou Erlang open source sob a licença EPL.

Quer mais uma boa notícia? Você não precisa de um servidor de aplicações para rodar sua aplicação Erlang, nem mesmo uma pesada IDE para escrevê-las. Tudo o que você precisa é de uma distribuição de Erlang para sua plataforma, seja Mac OS X, Linux, Windows, Solaris, ou qualquer outro sistema Unix-like, que traz consigo máquina virtual, compilador e vasta bibliotéca de módulos muito úteis – além do banco de dados Mnesia; e um editor de textos de sua preferência – TextMate, por exemplo, tem um ótimo bundle para Erlang.

Algumas características de Erlang

1- Expressividade e beleza

Há quem diga que não, mas Erlang é uma linguagem muito bonita — ao menos pra mim. Dado as já citadas influências de Erlang, ela é uma linguagem bem expressiva e declarativa, que encoraja a escrita de código simples e objetivo, o que certamente torna seu código fácil de ler, de escrever e de organizar [em módulos reutilizáveis]. O snippet abaixo é um exemplo de implementação do famoso fatorial:

-module(sample1).
-export([fac/1]).

fac(0) -> 1;
fac(N) -> N * fac(N-1).

2- Forte uso de recursividade

Isto certamente é uma herança da veia funcional de Erlang que torna o código muito menos imperativo e mais declarativo. Mas além da beleza declarativa óbvia, é importante saber que Erlang foi projetada para lidar com iterações recursivas gigantescas sem qualquer degradação – e sem estourar o “heap” de memória.

3- Livre de efeito colateral

Uma das grandes capacidades dadas por Erlang é a construção de sistemas altamente concorrentes rodando em processadores com multiplos núcleos. Isto não combina nada com efeito colateral, por isso, em Erlang, uma vez que um dado valor tenha sido atribuído a uma variável, esta não poderá mais ser modificada – ou seja, estão mais para o que conhecemos por constantes do que para o que conhecemos por variaveis.

Se você já escreveu código concorrênte sabe o quanto tê-lo livre de efeitos colaterais te faz livre de dores de cabeça. Poucas coisas são tão deprimentes quanto debugar código concorrênte repleto de efeitos colaterais.

4- Pattern matching

Pattern matching em Erlang é usado para associar valores a variáveis, controlar fluxo de execução de programs, extrair valores de estruturas de dados compostas e lidar com argumentos de funções. Mais um ponto para código declarativo e expressividade. Vejamos o código abaixo:

-module(sample2).
-export([convert_length/1]).

convert_length(Length) ->
    case Length of
        {centimeter, X} ->
            {inch, X / 2.54};
        {inch, Y} ->
            {centimeter, Y * 2.54}
    end.

Fala por si, não?

5- Concorrência baseada em passagem de mensagens (a.k.a. Actors)

Acho que concorrência baseada em passagem de mensagem entre atores é uma das features mais populares de Erlang. Vejamos o porque com o famoso exemplo do Ping-Pong:

-module(sample3).

-export([start/0, ping/2, pong/0]).

ping(0, Pong_PID) ->
    Pong_PID ! finished,
    io:format("Ping finished~n", []);

ping(N, Pong_PID) ->
    Pong_PID ! {ping, self()},
    receive
        pong ->
            io:format("Ping received pong~n", [])
    end,
    ping(N - 1, Pong_PID).

pong() ->
    receive
        finished ->
            io:format("Pong finished~n", []);
        {ping, Ping_PID} ->
            io:format("Pong received ping~n", []),
            Ping_PID ! pong,
            pong()
    end.

start() ->
    Pong_PID = spawn(sample3, pong, []),
    spawn(sample3, ping, [3, Pong_PID]).

Neste pequeno snippet podemos observar algumas características de Erlang já citadas neste post, tal como pattern matching na captura das mensagens e recursividade no controle das iterações.

Agora, falando do aspecto concorrente em sim, algumas coisas são particularmente interessantes aqui:

a. Em Erlang, a concorrência acontece entre processos leves, diferente de linguagens como C++ e Java, que baseiam sua concorrência em threads nativas de sistema operacional [caríssimas];
b. Em Erlang, há um tipo de dado chamado PID, o qual é o identificador do processo paralelo (mais conhecido como Actor) e para o qual as mensagens podem ser enviadas.

Releia o código acima com estas informações em mente e veja como concorrência em Erlang é algo completamente descomplicado e natural. Depois, pense no mesmo código implementado em C#, Java ou C++.

Gostei de Erlang, há algum livro para eu começar a estudar?

Sim, há dois livros excepcionais. Um, do próprio criador da linguagem, Joe Armstrong:

E outro de Francesco Cesarini e Simon Thompson:

Além disso, há o próprio material on line que é muito bom e barato.

Conclusão

Erlang possui muitas outras características e informações bem interessantes, mas que me falta espaço neste post para citar e apresentar, senão ele ficará absurdamente gigantesco para o meu gosto. Mas acredito que pelo que já apresentei até aqui, você já tenha motivos suficientes para pensar em Erlang com carinho e conciderá-la para seu próximo grande projeto.

Em breve devo escrever algo sobre OTP, já que neste post apresentei características mais inerentes à linguagem em si e nem tanto sobre a plataforma.

Até mais!

Então não deixe de visitar…

O site é recém-nascido, mas já tem uns recursos bem legais, como sistema de pesquisa por palavras-chave, núvem de tags e entre outros. Vale a pena conferir e acompanhar sua evolução – e oportunidades de bons trabalhos.

Mais uma iniciativa bem interessante da Caelum.

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.

Só tenho uma coisa a acrescentar, Jim: Quem mata gatinhos pequeninos quando alguém usa URL em lugar de URI, ou faz de um ESB um grande espaguete digno de festa do Bexiga, é o diabo, não Deus. Anote isso ai pra sua próxima aprensentação.

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!

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!

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.

Eu nunca programei uma única linha sequer de código em Clojure, apenas dei uma boa olhada no site oficial da linguagem para conhecer sua proposta – que é muito interessante, digasse de passagem – e tenho acompanhado as notícias que rolam aqui e ali. (Coisa de quem é vidrado por programação.)

No entanto, hoje, li uma notícia sobre Clojure que me fez pensar um pouco além da própria programação…

“Por que as pessoas normalmente não tentam fazer as coisas de outra maneira?”

Achei muito interessante o fato de terem usado Clojure, que é uma linguagem jovem, para implementar concorrência em um grande e importante sistema de informação, mesmo não havendo ainda relatos de que já o tenham feito antes.

Inovação, pioneirismo, pragmatismo… Pensamento fora da caixa!!!

Isso também é sobre ser inteligente. Se já inventaram a solução do problema de concorrência, de maneira elegante, por que ainda ficar batendo cabeça com linguagens “consolidadas”, mas que não o resolvem tão eficientemente? Aham? Por que a linguagem ainda é muito nova?

Esse é só um exemplo, mas há muitos outros em nosso dia a dia. Dê uma olhada ao seu redor. Dê uma olhada em seus próprios desafios. Aliás, aproveite, e dê uma olhada em suas próprias soluções!

O quanto você tem sido tradicionalista e conservador?

O medo das novas soluções, das novas maneiras de fazer as coisas, normalmente, são um atraso para os novos bons resultados. Afinal de contas, normalmente, quem sai na frente lucra primeiro…

Assumir o boné de arquiteto em um projeto de software é uma tarefa que requer maturidade, muito além do simples conhecimento técnico, pois boa parte do sucesso de um projeto de software depende de decisões arquitetônicas.

Presto consultoria nessa área há algum tempo, e não foi uma nem duas vezes que vi pessoas cometerem erros primários ao assumirem esse boné – ao ponto de quase levarem projetos à ruina. Baseado nessa experiência, quero citar cinco erros primários que um arquiteto pode cometer ao ignorar:

1- O time de desenvolvimento

Não, desenvolvedores não são como apertadores de porcas e parafusos de linha de produção. Se você ainda acredita no conto de fadas do processo fabril para desenvolvimento de software, sinto lhe dizer que isso não passa de balela. A verdade é que desenvolvimento de software é um processo criativo, mais humano que mecânico.

Assim, é preciso levar em conta que cada time de desenvolvimento é diferente do outro, tendo qualidades e deficiencias que de maneira alguma podem ser ignoradas. Ao contrario disso, devem ser colocadas sobre a mesa e ponderadas antes de quaisquer decisões arquitetônicas. Ignorar isso pode ser a ruina do projeto.

Portanto, não basta somente o “sr arquiteto” dominar as técnicas e tecnologias escolhidas para o projeto. É preciso que todo o time de desenvolvimento também esteja apto a operacionalizar cada decisão com qualidade.

Um bom arquiteto precisa saber trabalhar com o conhecimento e a experiência do time. Precisa constantemente promover a evolução técnica do time, mas também saber abrir mão da última versão daquele framework mais legal de todos, quando o time ainda não está apto a usá-lo e não há tempo hábil para capacitação.

Outra coisa fundamental é tornar o time de desenvolvimento participante nas decisões arquitetônicas do projeto. Isso torna o time mais convicto das decisões e também mais comprometido com a sua operacionalização.

2- O escopo do projeto

Não é incomum ver arquitetos querendo conceber soluções que vão atender os requisitos de hoje e os da próxima década. Isso é péssimo, porque leva a elocubrações sem fim. Além, é claro, do iminente risco de construir uma arquitetura frankenstein.

“Ah! Mas e se daqui a um ou dois anos vocês quiserem que o sistema de pagamento possa também receber pagamentos por moeda estelar? Será que não seria melhor se modelassemos algo mais flexivel?” – ah meu Deus!

Tenha bem claro qual o objetivo do projeto, onde ele começa e onde ele acaba. Não fique aquém, nem vá além.

Ah! E não se esqueça de deixar também o time de desenvolvimento bem ciente desses limites.

3- A compatibilidade

Não estabelecer claramente as versões de sistema operacional, banco de dados, IDE, frameworks e bibliotecas, com as quais o software em desenvolvimento deve ser compativel é roubada. Porque o que funciona na versão 1.0 do framework XPTO, talvez não funcione na versão 2.0. Quem garante? Eu que não me atrevo!

Já enfrentei tantos problemas trabalhando em projetos onde não existia essa prática que até me dá arrepio pensar nisso. Você debuga pra cá, debuga pra lá, e quando vai ver, foi um bendito JAR que foi mudado e ninguém te avisou, ou mesmo se preocupou em saber se quebraria o que você fez. Pior ainda quando isso acontecia no momento da implatação do produto final. Urgh!!!

Agora, como fazer isso de maneira eficiente? Bem, para o caso de bibliotecas e afins, sugiro que você dê uma olhada no Artifactory, ele serve de repositório para o Maven. E para sistema operacional, banco de dados, IDE, e outros elementos de infra, um quadro na parede já resolve bem o problema.

4- O design evolutivo

A chave para o design evolutivo é fazer o mais simples possível e ir refatorando depois, conforme a necessidade. Sim, o estado da arte nunca acontece na primeira implementação; tentar fazer isso pode leva-lo à ruina.

Seja prático. Primeiro tenha algo funcional; depois, evolua.

5- As opções de ferramentas

Como se diz “se você só tem um martelo, tende a enxergar todos os problemas como um prego”. Isso é perigoso, porque te faz desperdiçar tempo e dinheiro – e ainda conceber soluções burras.

Faz um bom tempo que o Phillip escreveu este post e ele ainda é muito atual. Infelizmente. Sim, infelizmente, porque ainda tem muita gente que se recusa a ter mais do que um martelo em sua caixa de ferramentas.

Trabalho com Java há muito tempo, mas hoje esta não é a única ferramenta em minha caixa. Há tantas ferramentas boas no mercado, porque ignorar isso?

Há ainda muitos outros erros, certamente…

Que tal você registrar alguns nos comentários deste post?

Valeu!

Nos últimos tempos tenho dedicado boa parte do meu tempo livre estudando JRuby. Tem sido uma verdadeira diversão!

Com o objetivo de compartilhar um pouco do que tenho aprendido, eis aqui este post…

Quer dizer que o osrevni inverso também é verdade?

Muito se fala da capacidade do JRuby de acessar código Java de maneira tão natural quanto o faz com seu próprio código – o que é definitivamente fantástico. Mas não tenho visto muitos exemplos de código Java acessando código JRuby. Por quê? Não sei dizer. Talvez porque não tenham visto tanta utilidade nisso. Essa não é minha opinião, já que tenho interesse em implementar algumas coisas em JRuby e usar a partir do Java.

Uma das coisas que fiz nesses meus estudos sobre usar JRuby a partir de Java foi testar o compilador jrubyc para gerar .class, mas não cheguei bem onde eu queria – até troque umas palavras com Charles Nutter a respeito -, porque o .class gerado por ele não é do tipo que se pode instanciar e usar diretamente num código Java, dada a natureza totalmente dinâmica de Ruby. Nas palavras do próprio Charles:

The code compiled by jrubyc is not a “normal” Java class[...] This is not a Java class you can instantiate and call methods on directly from Java[...].

Como não desisti, tenho algumas alternativas para compartilhar.

OBS.: Para executar os exemplos apresentados é necessário ter jruby.jar no classpath do seu projeto. Quando escrevi este post estava usando a versão 1.0, porque não havia uma versão mais atual na máquina que eu estava usando. Mas agora já atualizei o código para a versão 1.1.3.

Primeira alternativa: JRuby puramente Ruby

No exemplo abaixo, criou uma classe Ruby comum – sem qualquer recurso específico do JRuby – e, logo após, a carrego, instancio e executo seu método a partir do Java.

matematica_apenas_ruby.rb

class MatematicaApenasRuby
  def soma(a, b)
    a + b
  end
end

MatematicaApenasRubyTest.java

public class MatematicaApenasRubyTest {
    public static void main(String args[]) throws Exception {
        List pathsLoad = new ArrayList();
        pathsLoad.add("/Workspace/Ruby/IntegracaoJava/lib/");

        Ruby rubyRuntime = JavaEmbedUtils.initialize(pathsLoad);
        rubyRuntime.getLoadService().load("matematica_apenas_ruby.rb", false);

        Object mat_ruby = rubyRuntime.evalScriptlet("MatematicaApenasRuby.new");
        Integer res_ruby = (Integer)JavaEmbedUtils.invokeMethod(rubyRuntime, mat_ruby, "soma", new Integer[] {3, 2}, Integer.class);

        System.out.println("Soma 3 + 2 invocando diretamente JRuby: " + res_ruby);
    }
}

O que esse código Java faz é bem simples, ele:

1- Inicializa um ambiente de runtime para Ruby, indicando onde estão os arquivos .rb;
2- Executa o script de criação da classe MatematicaApenasRuby;
3- Executa o script de instanciação da classe MatematicaApenasRuby;
4- E, por fim, invoca o método soma passando dois parametros.

Que tal, acho simples? Pois muito bem, continuemos…

Segunda alternativa: JRuby implementando Java

Neste segundo exemplo, o que eu faço é criar uma classe JRuby que estende uma classes Java abstrata, o que facilita ainda mais na hora de usar a partir do Java. Vejamos como fica.

matematica_impl_java.rb

require 'java'

class MatematicaImplJava < Java::IntegracaoPoliglota::Matematica
  def soma(a, b)
    a + b
  end
end

Matematica.java

package integracao.poliglota;

public abstract class Matematica {
    public abstract int soma(int a, int b);
}

MatematicaImplJavaTest.java

public class MatematicaImplJavaTest {
    public static void main(String args[]) throws Exception {
        List pathsLoad = new ArrayList();
        pathsLoad.add("/Workspace/Ruby/IntegracaoJava/lib/");

        Ruby rubyRuntime = JavaEmbedUtils.initialize(pathsLoad);
        rubyRuntime.getLoadService().load("matematica_impl_java.rb", false);

        Object mat_impl_java = rubyRuntime.evalScriptlet("MatematicaImplJava.new");
        Matematica matematica = (Matematica)JavaEmbedUtils.rubyToJava(rubyRuntime, (IRubyObject)mat_impl_java, Matematica.class);

        System.out.println("Soma 10 + 2 usando a interface Java: " + matematica.soma(10, 2));
    }
}

E esta alternativa, gostou? Eu gostei bastante. Porque no meu caso, o que eu quero é poder definir uma interface em Java e implementar com JRuby a la Ruby Way e depois usar no Java. É claro que não estou levando em conta o fator “performance”, só estou considerando o fator “alternativa de implemententação”. Só isso.

Mas vamos lá, o que esse código faz?

1- A classe JRuby estende uma classe Java abstrata, como dito antes;
2- A classe que faz o teste, em linhas gerais, faz um cast do objeto JRuby para a classe Java abstrata;
3- E no final das contas, invoca o método da classe Java.

Será que programação poliglota é o futuro?

Se é ou não é, eu não sei. Mas sei que deixei de ser um arquiteto de uma nota só há muito tempo; e estou muito emplogado com JRuby – ele é o melhor dos dois mundos!

E você, o que acha? Deixe um comentário…