Jakarta Messaging - Jakarta Messaging

A Jakarta Messaging API (anteriormente Java Message Service ou JMS API) é uma interface de programação de aplicativos (API) Java para middleware orientado a mensagens . Ele fornece modelos de mensagens genéricos, capazes de lidar com o problema produtor-consumidor , que podem ser usados ​​para facilitar o envio e recebimento de mensagens entre sistemas de software . Jakarta Messaging é uma parte do Jakarta EE e foi originalmente definida por uma especificação desenvolvida na Sun Microsystems antes de ser orientada pelo Java Community Process .

Ideia geral de mensagens

Veja também: Middleware orientado a mensagens e passagem de mensagens

Mensagens é uma forma de comunicação distribuída fracamente acoplada , onde, neste contexto, o termo 'comunicação' pode ser entendido como uma troca de mensagens entre componentes de software. As tecnologias orientadas a mensagens tentam relaxar a comunicação fortemente acoplada (como soquetes de rede TCP , CORBA ou RMI ) pela introdução de um componente intermediário. Essa abordagem permite que os componentes de software se comuniquem uns com os outros indiretamente. Os benefícios disso incluem remetentes de mensagens que não precisam ter conhecimento preciso de seus destinatários.

As vantagens do sistema de mensagens incluem a capacidade de integrar plataformas heterogêneas, reduzir gargalos do sistema, aumentar a escalabilidade e responder mais rapidamente às mudanças.

Histórico de versão

  • JMS 1.0
  • JMS 1.0.1 (5 de outubro de 1998)
  • JMS 1.0.1a (30 de outubro de 1998)
  • JMS 1.0.2 (17 de dezembro de 1999)
  • JMS 1.0.2a (23 de dezembro de 1999)
  • JMS 1.0.2b (27 de agosto de 2001)
  • JMS 1.1 (12 de abril de 2002)
  • JMS 2.0 (21 de maio de 2013)
  • JMS 2.0a (16 de março de 2015)

JMS 2.0 é mantido atualmente no Java Community Process como JSR 343.

JMS 3.0 está em desenvolvimento inicial como parte do Jakarta EE.

Elementos

A seguir estão os elementos JMS:

Provedor JMS
Uma implementação da interface JMS para middleware orientado a mensagem (MOM). Os provedores são implementados como uma implementação Java JMS ou um adaptador para um MOM não Java.
Cliente JMS
Um aplicativo ou processo que produz e / ou recebe mensagens.
Produtor / editor JMS
Um cliente JMS que cria e envia mensagens.
Consumidor / assinante JMS
Um cliente JMS que recebe mensagens.
Mensagem JMS
Um objeto que contém os dados que estão sendo transferidos entre clientes JMS.
Fila JMS
Uma área de teste que contém mensagens que foram enviadas e estão esperando para serem lidas (por apenas um consumidor). Como o nome da fila sugere, as mensagens são entregues na ordem de envio. Uma fila JMS garante que cada mensagem seja processada apenas uma vez.
Tópico JMS
Um mecanismo de distribuição para publicar mensagens que são entregues a vários assinantes.

Modelos

A API JMS oferece suporte a dois modelos distintos:

  • Ponto a ponto
  • Publicar e assinar

Modelo ponto a ponto

No sistema de mensagens ponto a ponto , as mensagens são roteadas para consumidores individuais que mantêm filas de mensagens recebidas. Esse tipo de mensagem baseia-se no conceito de filas de mensagens , remetentes e destinatários. Cada mensagem é endereçada a uma fila específica e os clientes receptores extraem mensagens das filas estabelecidas para reter suas mensagens. Embora qualquer número de produtores possa enviar mensagens para a fila, é garantido que cada mensagem seja entregue e consumida por um consumidor. As filas retêm todas as mensagens enviadas a elas até que sejam consumidas ou expirem. Se nenhum consumidor estiver registrado para consumir as mensagens, a fila as reterá até que um consumidor se registre para consumi-las.

Modelo de publicação e assinatura

O modelo publicar e assinar oferece suporte à publicação de mensagens em um "tópico" de mensagem específico. Os assinantes podem registrar interesse em receber mensagens publicadas sobre um determinado tópico de mensagem. Nesse modelo, nem o editor nem o assinante se conhecem. Uma boa analogia para isso é um quadro de avisos anônimo.

  • Zero ou mais consumidores receberão a mensagem.
  • Existe uma dependência de tempo entre editores e assinantes. O editor deve criar um tópico de mensagem para os clientes assinarem. O assinante deve permanecer continuamente ativo para receber mensagens, a menos que tenha estabelecido uma assinatura durável. Nesse caso, as mensagens publicadas enquanto o assinante não está conectado serão redistribuídas sempre que ele se reconectar.

JMS fornece uma maneira de separar o aplicativo da camada de transporte de fornecimento de dados. As mesmas classes Java podem ser usadas para se comunicar com diferentes provedores JMS usando as informações de Java Naming and Directory Interface (JNDI) para o provedor desejado. As classes primeiro usam um connection factory para se conectar à fila ou tópico e, em seguida, preenchem e enviam ou publicam as mensagens. No lado receptor, os clientes então recebem ou assinam as mensagens.

Esquema URI

A RFC 6167 define um jms: esquema de URI para o Java Message Service.

Implementações de provedor

Para usar o JMS, é necessário ter um provedor JMS que possa gerenciar as sessões, filas e tópicos. A partir do Java EE versão 1.4, um provedor JMS deve estar contido em todos os servidores de aplicativos Java EE. Isso pode ser implementado usando o gerenciamento de fluxo de mensagens do Java EE Connector Architecture , que foi disponibilizado pela primeira vez nessa versão.

A seguir está uma lista de provedores JMS comuns:

Veja também

Referências

Leitura adicional

  • Richards, Mark; Richard Monson-Haefel; David A. Chappell (2009). Java Message Service, segunda edição . O'Reilly. ISBN 978-0-596-52204-9.

links externos