Neste post, faço um resumo da arquitetura de JMS, que é definido pelo item 2 da especificação JMS 1.1.
O item 2.2 define os possíveis participantes de uma aplicação JMS:
• Cliente JMS - Cliente JMS que utiliza linguagem java.
• Cliente não-JMS - Possíveis clientes JMS de uma aplicação escritos utilizando uma linguagem proprietária do provider. Como exemplo pode-se citar um cliente do IBM MQ escrito utilizando uma API proprietária do produto.
• Mensagens - Estas são as mensagens postadas e consumidas no MOM(Message Oriented Middleware).
• Provider JMS - Este é o MOM em si que pode fornecer serviços adicionais à especificação para seus clientes, como é o caso da maioria dos providers.
• Objetos Administrativos - São objetos pré-configurados no provider para facilitar a vida dos clientes, usualmente os objetos são ConnectionFactory e Destinations, estes objetos são registrados na árvore JNDI do servidor por default ou pelos administradores do MOM utilizado.
O modelo de Administração definido é o que proporciona interoperabilidade das aplicações escritas em JMS, isso porque os objetos ConnectionFactory e Destinations são padronizados e as APIs de acesso a estes recursos, fornecidas usualmente pelos providers, disponibilizam interfaces padrão para sua utilização.
ConnectionFactory - Objeto utilizado por clientes para criar uma conexão com o provider utilizado.
Destination - Objeto que o cliente usa para especificar o destino de envio ou recebimento de mensagens.
Estes objetos devem ser disponibilizados na árvore JNDI(Java Naming and Directory Interface) do servidor(JNDI Namespace), possibilitando acesso padronizado através da API padrão de java. Conforme imagem abaixo tirada da especificação JMS 1.1.
Conforme mencionado anteriormente existem dois tipos de mensagens que podem ser utilizadas conforme a especificação: Point-to-Point ou Publish/Subscriber Messages.
A especificação define então algumas APIs que possibilitam a utilização do tipo de mensagem desejado e ainda um conjunto de interfaces que abstrai essa implementação, conforme o quadro abaixo, retirado da especificação, ilustra.
Segue uma breve definição dos objetos da interface comum:
• ConnectionFactory - Objeto administrativo utilizado pelo cliente para criar uma conexão com o provider.• Connection - uma conexão estabelecida com o provider.
• Destination - um destino de envio ou recebimento de mensagens.
• Session - um contexto criado com o provider para envio ou recebimento de mensagens.
• MessageProducer - Um objeto criado por uma sessão que efetivamente é utilizado apra envio de mensagens ao destino.
• MessageConsumer - Um objeto criado por uma sessão que é utilizado para consumir mensagens de um destino.
Conforme já foi mencionado, outros serviços não definidos pela especificação podem ser adicionados pelo fornecedor do provider e portanto, os modos de Administração, segurança, timers, dentre outros serviços, podem ser proprietários e definidos através de APIs de cada fornecedor do MOM(provider).
Na questão de acesso concorrente, a tabela mostrada abaixo, retirada da especificação, ilustra bem o modelo utilizado.
A especificação prevê ainda um modelo de Request/Reply para as mensagens poderem definir um estado de conversação. Para isso, é definido no header das mensagens um campo denominado JMSCorrelationID que pode ser utilizado para este fim.
[]s
Nenhum comentário:
Postar um comentário