AN style="FONT-SIZE: 10pt; BACKGROUND: white; COLOR: red; FONT-FAMILY: Verdana; moz-background-clip: -moz-initial; moz-background-origin: -moz-initial; moz-background-inline-policy: -moz-initial">
N-US style="FONT-SIZE: 10pt; COLOR: windowtext; FONT-FAMILY: Verdana">
De que se trata o artigo:
Consumir mensagens JMS com Message-Driven Beans e annotations na versão 3.0 do EJB, facilitando assim a interligação de sistemas e funcionalidades.
Para que serve:
Facilitar o consumo de mensagens JMS sem ter que se preocupar com uma parte da infra-estrutura do projeto como pool de objetos, threads, sincronização, etc. E aumentar o desempenho do processo como um todo com chamadas assíncronas aos objetos que consomem as mensagens JMS.
Em que situação o tema é útil:
Expõe para desenvolvedores que utilizam sistemas de mensagens (MOMs) como é fácil consumir essas mensagens utilizando o Message-Driven Beans com annotations do EJB 3.0. Para quem tem uma funcionalidade desenvolvida em um container EJB (um Session Beans, por exemplo) e queira disponibilizar essa funcionalidade sem que a mesma fique acoplada ao cliente.
Message-Driven Beans – Resumo DevMan:
O artigo mostra como ficou fácil consumir mensagens dos MOMs com Message-Driven Beans e annotations na versão 3.0 do EJB. Explicamos alguns conceitos básicos de MDB, como características e ciclo de vida, e alguns conceitos avançados de MDB, como load balancing e transações. Também mostraremos um exemplo simples e prático de como criar um MDB e um cliente JMS funcionando com o Glassfish.
No ambiente corporativo, é comum a necessidade de integração entre sistemas. Existem várias alternativas para tal integração, sendo que uma delas, já há anos consolidada no mercado, é a integração através de troca de mensagens. Por mensagens, entende-se não apenas textos simples, mas também objetos complexos. Para o leitor iniciante no assunto, veja antes o quadro “API JMS e MOM”, que dá uma explicação resumida de JMS (Java Message Service) e MOM (Message-oriented middleware).
Com o objetivo de facilitar o desenvolvimento e também aumentar a performance com chamadas assíncronas aos objetos que consomem as mensagens JMS, surgiu o MDB (Message-Driven Beans). MDB é um componente que executa determinada lógica de negócio desenvolvida pelo programador, e é invocado pelo container no momento que uma mensagem chega na fila à qual ele está associado. Utilizando MDB o desenvolvedor não precisa se preocupar com aspectos como infra-estrutura, segurança, concorrência e transações. Dessa forma, o desenvolvedor pode focar seu esforço na lógica de negócios do cliente, que é o que realmente importa. O MDB surgiu na especificação 2.0 do EJB, mas, com a entrada de annotations na versão 3.0, ficou muito mais fácil criar e configurar esses tipos de objetos. Por isso, nosso artigo utiliza somente annotations, apesar de também ser possível trabalhar com XML na versão atual do EJB.
Características de um MDB
- Os MDBs não possuem interfaces de negócios locais ou remotas, como as dos Sessions Beans. Dessa forma, o cliente não interage diretamente com um MDB, ele somente interage com MDB através de um sistema de gerenciamento de mensagens e do container EJB, que faz com que essas mensagens sejam entregues aos componentes MDB;
- Na grande maioria dos casos, não faz sentido um MDB retornar um objeto ou uma exception ao cliente que enviou a mensagem, pois como o cliente está desacoplado do componente MDB, ele não fica esperando para recuperar um objeto ou para saber se houve algum erro de processamento para poder continuar com sua lógica de negócios; mas como a especificação do EJB não restringe o retorno de objetos ou exceptions, é possível fazer isso com ajuda de algumas técnicas;
- MDBs são single-threaded, ou seja, cada instância criada consome somente uma mensagem por vez. Felizmente o desenvolvedor não precisa se preocupar com este gerenciamento, pois o container EJB faz isso automaticamente, criando um pool de threads para atendimento concorrente a múltiplas mensagens;
- Apesar dos MDBs não possuírem estado conversacional com seus clientes, variáveis de instância podem manter o estado através das manipulações de mensagens. Um exemplo disso é a conexão com um banco de dados ou uma referência para um EJB.
...
