Respostas:
O JMS (ActiveMQ é uma implementação do broker JMS) pode ser usado como um mecanismo para permitir o processamento de solicitações assíncronas. Você pode fazer isso porque a solicitação demora muito para ser concluída ou porque várias partes podem estar interessadas na solicitação real. Outro motivo para usá-lo é permitir que vários clientes (potencialmente gravados em idiomas diferentes) acessem informações via JMS. O ActiveMQ é um bom exemplo aqui, porque você pode usar o protocolo STOMP para permitir o acesso de um cliente C # / Java / Ruby.
Um exemplo do mundo real é o de um aplicativo Web usado para fazer um pedido para um cliente específico. Como parte da colocação desse pedido (e do armazenamento em um banco de dados), você pode realizar várias tarefas adicionais:
Para fazer isso, o código do aplicativo publicaria uma mensagem em uma fila JMS que inclui um ID do pedido. Uma parte do seu aplicativo que está ouvindo a fila pode responder ao evento pegando o orderId, procurando o pedido no banco de dados e, em seguida, faça esse pedido com outro sistema de terceiros. Outra parte do seu aplicativo pode ser responsável por receber o orderId e enviar um e-mail de confirmação ao cliente.
Use-os o tempo todo para processar operações de longa execução de forma assíncrona. Um usuário da web não vai querer esperar mais de 5 segundos para processar uma solicitação. Se você tiver um que seja mais longo que isso, um design será enviar a solicitação para uma fila e enviar imediatamente de volta uma URL que o usuário pode verificar para ver quando o trabalho é concluído.
A publicação / assinatura é outra boa técnica para dissociar remetentes de muitos receptores. É uma arquitetura flexível, porque os assinantes podem entrar e sair conforme necessário.
Eu tive tantos usos incríveis para o JMS:
Comunicação por bate-papo na Web para atendimento ao cliente.
Depuração de log no back-end. Todos os servidores de aplicativos transmitiram mensagens de depuração em vários níveis. Um cliente JMS pode então ser iniciado para observar as mensagens de depuração. Claro que eu poderia ter usado algo como syslog , mas isso me deu todo tipo de maneira de filtrar a saída com base em informações contextuais (eq pelo nome do servidor de aplicativos, chamada da API, nível da log, ID do usuário, tipo de mensagem, etc.). Também colori a saída.
Depurar o log no arquivo. Da mesma forma que acima, apenas partes específicas foram extraídas usando filtros e registradas no arquivo para registro geral.
Alertando. Novamente, uma configuração semelhante ao registro acima, observando erros específicos e alertando as pessoas por vários meios (email, mensagem de texto, mensagens instantâneas, pop-up Growl ...)
Configurando e controlando dinamicamente clusters de software. Cada servidor de aplicativos transmitia uma mensagem "configure me" e, em seguida, um daemon de configuração que respondia com uma mensagem contendo todos os tipos de informações de configuração. Mais tarde, se todos os servidores de aplicativos precisassem que suas configurações fossem alteradas ao mesmo tempo, isso poderia ser feito no daemon de configuração.
E as transações usuais na fila para atividades atrasadas, como cobrança, processamento de pedidos, provisionamento, geração de e-mail ...
É ótimo em qualquer lugar que você queira garantir a entrega de mensagens de forma assíncrona.
Computação síncrona distribuída.
Um exemplo do mundo real pode ser uma estrutura de notificação para todo o aplicativo, que envia e-mails para as partes interessadas em vários pontos durante o curso do uso do aplicativo. Portanto, o aplicativo atuaria como um Producercriando um Messageobjeto, colocando-o em particular Queuee seguindo em frente.
Haveria um conjunto de Consumers que assinaria o item Queueem questão e cuidaria de lidar com os Messageenviados. Observe que durante o curso dessa transação, os Producers são dissociados da lógica de como um dado Messageseria tratado.
As estruturas de mensagens (ActiveMQ e similares) atuam como uma espinha dorsal para facilitar essas Messagetransações, fornecendo MessageBrokers.
Usei-o para enviar transações intradia entre diferentes sistemas de gestão de fundos. Se você quiser saber mais sobre o que é uma ótima mensagem de tecnologia, recomendo completamente o livro " Padrões de integração corporativa ". Existem alguns exemplos JMS para coisas como solicitação / resposta e publicação / assinatura.
O sistema de mensagens é uma excelente ferramenta para integração.
Nós o usamos para iniciar o processamento assíncrono que não queremos interromper ou entrar em conflito com uma transação existente.
Por exemplo, digamos que você tenha uma peça de lógica cara e muito importante, como "comprar itens", uma parte importante do item "compras" seria "notificar itens". Tornamos a chamada de notificação assíncrona para que qualquer lógica / processamento envolvido na chamada de notificação não bloqueie ou contenda recursos com a lógica de negócios de compra. Resultado final, compra concluída, usuário fica feliz, recebemos nosso dinheiro e, como a fila é entrega garantida, a loja é notificada assim que é aberta ou assim que há um novo item na fila.
Eu o usei para o meu projeto acadêmico, que era um site de varejo on-line semelhante ao da Amazon. O JMS foi usado para lidar com os seguintes recursos:
Também tivemos vários clientes remotos implementados, conectados ao servidor principal. Se a conexão estiver disponível, eles usam para acessar o banco de dados principal ou, se não, usam seu próprio banco de dados. Para lidar com a consistência dos dados, implementamos o mecanismo 2PC. Para isso, usamos o JMS para trocar as mensagens entre esses sistemas, ou seja, um atuando como coordenador que iniciará o processo enviando mensagem na fila e outros responderão de acordo enviando novamente uma mensagem na fila. Como outros já mencionaram, isso foi semelhante ao modelo pub / sub.
Vi o JMS usado em diferentes projetos comerciais e acadêmicos. O JMS pode facilmente entrar em cena, sempre que você quiser ter um sistema distribuído totalmente dissociado. De um modo geral, quando você precisa enviar sua solicitação a partir de um nó, alguém da sua rede cuida dela sem / com fornecer ao remetente qualquer informação sobre o destinatário.
No meu caso, usei o JMS no desenvolvimento de um MOM (middleware orientado a mensagens) em minha tese, em que tipos específicos de objetos orientados a objetos são gerados de um lado como sua solicitação e compilados e executados do outro lado como sua resposta .
O Apache Camel usado em conjunto com o ActiveMQ é uma ótima maneira de executar padrões de integração corporativa
Estamos usando o JMS para comunicação com sistemas em um grande número de sites remotos através de redes não confiáveis. O acoplamento flexível, combinado com mensagens confiáveis, produz um cenário estável do sistema: cada mensagem será enviada assim que for tecnicamente possível, problemas maiores na rede não terão influência em todo o cenário do sistema ...