Alguns
autores consideram como quinto elemento os clientes nativos, que
utilizavam as APIs de mensagens nativas e depois passaram a usar também
a JMS API.
O JMS Provider
é uma aplicação que fornece controle e administração aos serviços
oferecidos pela tecnologia JMS. Compare o JMS Provider com o Container
EJB, ou Servlet Container. É ele que gerencia o envio e o recebimento das
mensagens pelos clientes. Funciona como um Daemon (processo) rodando em
background, escutando solicitações em uma porta. Como exemplo de suas
funções, podemos citar que é ele o responsável pelo armazenamento de
uma mensagem que não puder ser entregue. Entre as aplicações comerciais
podemos citar: SonicMQ (www.progress.com) distribuído em conjunto com o
JBuilder da Borland, e o MQSeries (www.ibm.com) da IBM. Entre as
ferramentas open source temos o provider OpenJms (www.openjms.org), Joram
(www.objectweb.org) e o JbossQM, distribuído junto com o
Jboss(www.jboss.org). Vale lembrar que a comunidade open source e as
grandes empresas privadas estão aceitando cada vez mais a API JMS e,
assim, fornecendo ferramentas cada vez mais compatíveis.
De uma forma simples, podemos descrever o fluxo de uma
aplicação JMS assim: o cliente JMS produtor cria uma mensagem e a envia
para um destino no Provider. O Provider avisa aos clientes consumidores
que possui mensagens para serem lidas ou as armazena até serem
consumidas. Diferente dos clientes os Providers podem se comunicar
diretamente. Mas como existem Providers pertencentes a diferentes
fornecedores, pode haver problemas de incompatibilidade. Para resolver
isso, diversos fornecedores já implementam os chamados bridge:
componentes que atuam como uma ponte entre os Service Providers.
A especificação atual da JMS possibilita as duas
seguintes formas, chamadas de domínio, para trabalhar:
• Point-to-Point (figura 2)
• Publish/Subscribe (figura 3)
No domínio Point-to-Point (também chamado, PTP)
existe basicamente a presença de três elementos: uma fila (Queue), um
produtor e um consumidor. Cada mensagem é enviada para uma Queue, de onde
é consumida. O Provider, de acordo com os parâmetros passados pela
mensagem, pode armazená-la até que sejam consumidas ou seu tempo expire.
Como características desse domínio podemos citar:
• Cada mensagem tem apenas um consumidor
• O produtor e o consumidor não mantêm relação
de tempo entre eles
• O consumidor reconhece quando a mensagem é processada corretamente
No modelo Publish/Subscribe (também chamado pub/sub) as
mensagens são direcionadas para um tópico (Topic) e então entregues
para os vários clientes inscritos naquele tópico. Por default as
mensagens só são entregues aos clientes que estão ativos naquele
instante. Para resolver esse problema devemos criar as mensagens do tipo
"Durable". Veja mais informações no quadro "Aplicações
Robustas" e no exemplo ao final.
A leitura dessas mensagens pode ser feita de duas
formas: síncrona e assíncrona. Na primeira há a chamada ao método
receive, onde a aplicação espera pela mensagem ou então que acabe o
tempo de espera. Na segunda maneira, registramos um listener (ouvinte) que
está associado ao consumidor. Quando a mensagem chega, o listener é
avisado e então ativa o processo de busca.
A partir daqui, ao tratar os objetos usados pela JMS
API devemos fazer a distinção de qual domínio usar. Para cada domínio
teremos objetos administrativos diferentes. A forma mais simples de
diferenciar tais objetos é por sua nomenclatura. Para o modelo PTP,
teremos a presença de uma Queue (fila) e, por isso, os objetos levam essa
terminologia agregada ao seu nome. Pelo mesmo motivo, o domínio pub/sub
utiliza-se do Topic. Exemplificando: o objeto ConnectionFactory para o
domínio PTP chama-se QueueConnectionFactory e para o domínio pub/sub,
TopicConnectionFactory.
Conhecendo a arquitetura podemos agora partir para a
API de programação.
Leia na revista MundoJava o restante do artigo...
|
