o que é bom para JMS? [fechadas]

https://stackoverflow.com/questions/222017

03-07-2019
|

Pergunta

Eu estou procurando (simples) exemplos de problemas para os quais JMS é uma boa solução, e também razões pelas quais JMS é uma boa solução para esses casos. No passado, eu simplesmente usado o banco de dados como um meio de transmissão de mensagens de A para B quando a mensagem não pode necessariamente ser processado por B imediatamente.

Um exemplo hipotético de tal sistema um é onde todos os usuários recém-registrados deve ser enviada uma recepção de e-mail dentro de 24 horas de registro. Por uma questão de argumento, suponha que a DB não registrar o momento em que cada utilizador registado, mas em vez disso uma referência (chave estrangeira) para cada novo usuário é armazenado na tabela de pending_email. As execuções de tarefa e-mail do remetente, uma vez a cada 24 horas, envia um e-mail a todos os usuários nesta tabela, em seguida, exclui todos os registros pending_email.

Este parece ser o tipo de problema para o qual JMS deve ser usada, mas não é claro para mim que benefício JMS teria sobre a abordagem que eu descrevi. Uma vantagem da abordagem DB é que as mensagens são persistentes. Eu entendo que JMS filas de mensagens também podem ser persistentes, mas, nesse caso, parece haver pouca diferença entre JMS e do "banco de dados como fila de mensagens" aproximar eu descrevi?

O que eu estou ausente? - Don

Solução

JMS e mensagens é realmente sobre 2 coisas totalmente diferentes.

publicar e assinar (enviando uma mensagem para o maior número de consumidores estão interessados ??- um pouco como enviar um email para uma lista de discussão, o remetente não precisa saber quem é subscrito
alto desempenho confiável balanceamento de carga (filas de mensagens)

Veja mais informações sobre como uma fila compara a um tópico

O caso que você está falando é o segundo caso, em que sim, você pode usar uma tabela de banco de dados para simular meio de uma fila de mensagens.

A principal diferença é uma fila JMS mensagem é um alto desempenho balanceador de carga altamente concorrente projetado para grande rendimento; você pode enviar normalmente dezenas de milhares de mensagens por segundo para muitos consumidores simultâneos em vários processos e threads. A razão para isto é que uma fila de mensagens é basicamente altamente assíncrono - um provedor de boa JMS irá transmitir mensagens antes do tempo para cada consumidor modo que existem milhares de mensagens disponível para ser processado na RAM, logo que um consumidor está disponível. Isto leva a throughtput enorme e muito baixa latência.

por exemplo. imaginar escrevendo um balanceador de carga web usando uma tabela de banco de dados:)

Ao usar uma tabela de banco de dados, tipicamente um segmento tende a bloquear a tabela inteira para que você tendem a ficar muito baixa taxa de transferência quando tentam implementar um balanceador de carga de alto desempenho.

Mas como a maioria middleware, tudo depende do que você precisa; Se você tem uma baixa taxa de transferência do sistema com apenas algumas mensagens por segundo - sinta-se livre para usar uma tabela de banco de dados como uma fila. Mas se você precisar de baixa latência e alto rendimento -., Em seguida, JMS filas são altamente recomendado

Outras dicas

Em meus JMS de opinião e outros sistemas baseados em mensagens se destinam a resolver problemas que precisam:

Asynchronous comunicações:. Uma necessidade aplicativo para notificar outro que um evento ocorreu, sem necessidade de esperar por uma resposta
Confiabilidade . Garantir a entrega de mensagens de uma vez e somente-uma vez. Com o DB se aproximar de você ter de "reinventar a roda", especialmente se você tiver vários clientes ler as mensagens.
solto acoplamento . Nem todos os sistemas podem se comunicar usando um banco de dados. Então JMS é bom bastante para ser usado em ambientes heterogêneos com sistemas dissociados que podem se comunicar através de fronteiras do sistema.

A implementação JMS é "push", no sentido de que você não tem que pesquisar a fila para descobrir novas mensagens, mas você registrar um callback que é chamado assim que chega uma nova mensagem.

para abordar o comentário original. que foi originalmente descrito é a essência do (ponto-a-ponto) JMS. os benefícios de JMS são, no entanto:

Você não precisa escrever o código você mesmo (e possivelmente estragar a lógica para que ele não é tão persistente como você pensa que é). Além disso, de terceiros impl pode ser mais escalável do que a abordagem de banco de dados simples.
jms alças de publicação / assinatura, que é um pouco mais complicado que o exemplo ponto-a-ponto que você deu
você não está amarrado a uma aplicação específica, e podem trocá-lo se suas necessidades mudarem no futuro, w / out mexer w / o seu código Java.

Uma vantagem de JMS é para permitir o processamento assíncrono que pode por realizado por solução de base de dados, bem. Contudo seguintes são algum outro benefício de JMS sobre solução de banco de dados

a) O consumidor da mensagem pode estar em um local remoto. Expondo banco de dados para acesso remoto é perigoso. Você pode solucionar esse, fornecendo serviço adicional para a leitura de mensagens do banco de dados, que exige mais esforço.

b) No caso do banco de dados do consumidor mensagem tem de consultar o banco de dados para mensagens onde, como JMS fornece retorno de chamada quando uma mensagem é chegado (como sk mencionado)

c) Balanceamento de carga -. Se há grande quantidade de mensagens que chegam é fácil ter piscina de processadores de mensagens no JMS

d) Na aplicação geral via JMS será mais simples e ter menos esforço do que rota banco de dados

JMS é uma API usado para transferir mensagens entre dois ou mais clientes. É especificações são definidas sob JSR 914.

A grande vantagem do JMS é a natureza dissociada das entidades comunicantes - necessidade remetente não tem informações sobre os receptores. Outras vantagens incluem a capacidade de integrar plataformas heterogêneas, reduzir os gargalos do sistema, aumentar a escalabilidade e responder mais rapidamente às mudanças.

JMS são apenas uma espécie de interfaces / APIs e as classes concretas devem ser implementadas. Estes já são implementadas por várias organizações / Provedores. eles são chamados de provedores JMS. Exemplo é WebSphere pela IBM ou FioranoMQ por Fiorano Softwares ou ActiveMQ pelo Apache, HornetQ, OpenMQ etc. outras terminologias utilizadas são objetos admin (tópicos, filas, ConnectionFactories), JMS produtor / editor, o cliente JMS e a própria mensagem.

Assim que vem à sua pergunta - what is JMS good for? Eu gostaria de dar um exemplo prático para ilustrar a sua importância.

Dia de Negociação

Não é este recurso chamado LVC (cache Última valor)

preços das ações na negociação são publicados por uma editora em intervalos regulares. Cada ação tem um tópico associado ao qual está publicado. Agora, se você sabe o que um Tópico é então você deve saber as mensagens não são salvos como filas. As mensagens são publicadas para os assinantes vivo na época a mensagem foi publicado (exceção sendo Duráveis ??assinantes que recebem todas as mensagens publicadas a partir do momento em que foi criado, mas depois, novamente, não querem obter os preços das ações também antigos que descartar a possibilidade de usando isso). Portanto, se um cliente quer saber um preço das ações que criar um assinante e, em seguida, ele tem que esperar até o próximo preço das ações é publicado (que novamente não é o que queremos). Este é o lugar onde LVC entra em cena. Cada mensagem LVC tem uma chave associada. Se uma mensagem é enviada com uma chave LVC (para um estoque particular) e, em seguida, outra mensagem de atualização com a mesma chave-los mais tarde substitui o anterior. Sempre que um assinante subscreve um tema (que tem LVC ativado) o assinante receberá todas as mensagens com chaves distintas LVC. Se mantivermos uma chave distinta por empresa listada, em seguida, quando subscreve cliente para que ele irá obter as últimas preço das ações e, eventualmente, todas as atualizações.

Claro que este é um dos outros fatores que confiabilidade, segurança etc que torna JMS tão poderoso.

Guido tem a definição completa. Da minha experiência de todos estes são importantes para um bom ajuste.

Um dos usos que eu vi é para distribuição ordem em armazéns. Imagine que uma empresa de material de escritório que tem um bom número de armazéns que abastecem grandes escritórios com material de escritório. Essas ordens entraria em uma localização central e, em seguida, ser agrupadas para o armazém correto para distribuir. Os armazéns não tem ou quer conexões de alta velocidade na maioria dos casos para que os pedidos são empurrados para baixo a eles através de modems dial-up e isso é onde assíncrona entra. As linhas de telefone não são realmente tão importante tanto para que metade das ordens pode entrar e este é onde a confiabilidade é importante.

A principal vantagem é a dissociação sistemas não relacionados ao invés de tê-los compartilhar bancos de dados comon ou a construção de serviços personalizados para passar dados ao redor.

Os bancos são um exemplo afiado, com mensagens intraday sendo usado para passar as alterações de dados em torno ao vivo como eles acontecem. É muito fácil para o sistema de origem para lançar uma mensagem "por cima do muro"; A desvantagem é que há muito pouco na forma de contrato entre estes sistemas, e você normalmente vê hospitalização sendo implementado no lado do consumidor. É quase demasiado loosly acopladas.

Outras vantagens estão abaixo do suporte para JMS fora da caixa para muitos servidores de aplicação, etc., e todas as ferramentas ao redor que: durabilidade, monitoramento, relatórios e otimização

Há um bom write-up com alguns exemplos aqui: http: //www.winslam .com / Laramee / jms / index.html

O 'banco de dados como mensagem de fila' solução pode ser pesado para a tarefa. A solução JMS é menos fortemente acoplados em que o remetente da mensagem não precisa saber nada sobre o destinatário. Isto poderia ser conseguido com alguma abstração adicional no 'banco de dados como mensagem de fila', bem por isso não é uma grande vitória ... Além disso, você pode usar a fila de uma maneira 'publicar e assinar', que pode ser útil dependendo do que você está tentando realizar. É também uma boa maneira de ainda dissociar os seus componentes. Se toda a sua comunicação é dentro de um sistema e / ou ter um registro que está imediatamente disponível para uma aplicação é muito importante, o método parece bom. Se você está se comunicando entre sistemas separados JMS é uma boa escolha.

JMS em combinação com JTA (Java Transaction API) e JPA (Java Persistence API) pode ser muito útil. Com uma simples anotação você pode colocar várias ações de banco de dados + mensagem de envio / recebimento na mesma transação. Então, se um deles falhar tudo é revertida usando o mesmo mecanismo transação.

Licenciado em: CC-BY-SA com atribuição

Não afiliado a StackOverflow