JMS e REST não são mutualmente exclusivos. Você pode utilizar REST e ter uma parte com JMS. Acho que você compreendeu JMS de uma forma não tão correta.
JMS serve para trabalhar de forma assíncrona do lado do servidor.
Por exemplo: imagine que você está confirmando uma compra numa loja online. Na hora que você clica no último botão, de finalizar a compra, é enviada uma requisição para o servidor, certo? Nesse momento, uma série de medidas tem que ser tomadas. Dentre elas:
- Separar o produto no sistema de estoque;
- Confirmar o cartão de crédito com um sistema de terceiros;
- Gerar a nota fiscal;
E muitas outras coisas. Se tudo isso fosse feito de forma síncrona, teríamos alguns problemas, como:
- O navegador ia ficar naquele estado de “carregando”, por um bom tempo, até tudo ser concluído e a resposta ser retornada para você;
- As vezes, os sistemas intermediários (como o do cartão de crédito e o da receita federal) não estão disponíveis an hora que você fez a compra. O que fazer? Cancelar tudo? Esperar um pouco (e deixar o cliente esperando) e tentar de novo?
Para isso que serve a abordagem assíncrona. Quando você clica em finalizar, o servidor te retorna imediatamente uma página dizendo: “Obrigado pela compra! Em alguns instantes vamos te mandar os detalhes por email”.
O que o servidor fez:
- Coletou os dados da compra e enviou para uma fila de processamento assíncrono. Essa chamada, falando de código, retorna imediatamente;
- Te devolveu a página de agradecimento
Existe outro sistema intermediário, chamado de MOM (Message-Oriented Middleware), que é o gerenciador dessa fila de processamento. O MOM é o responsável por gerenciar (receber e enviar) a comunicação assíncrona entre sistemas distribuídos (nesse caso, a loja e o processador de compras).
Um terceiro sistema, que seria o processador de compras, vai ficar consumindo mensagens do MOM. Toda vez que chega uma mensagem de uma compra nova, por exemplo, ele vai fazer os passos que eu citei anteriormente, a parte do cartão de crédito, nota fiscal, estoque, etc. Se algo der errado, basta tentar novamente depois de um tempo, ou dar um rollback na transação e avisar o cliente de que algo errado ocorreu (através de email, por exemplo).
Trabalhar de forma assíncrona não precisa ter necessariamente a ver com não deixar o usuário esperando. Existem arquiteturas onde a abordagem assíncrona pode melhorar o desempenho da aplicação de forma geral. Existem porém, casos onde todo o processo deve ser executado de forma síncrona. Depende da aplicação.
É exatamente isso que descreve a especificação JMS. Uma API para produção e consumo de mensagens assíncronas. Mensagem num sentido muito mais genérico do que uma mensagem de chat, significando qualquer unidade de trabalho à ser processada.
Para trabalhar com mensagens, uma abordagem interessante pode ser a utilização de web sockets.