Comecei a estudar um pouco de JMS (Java Message Service) e a primeira dúvida que surgiu foi a seguinte:
O que tem de diferente JMS e WebServices?
Ao invés de pesquisar por exemplos estanques, gostaria de ouvir opiniões de quem conhece os dois padrões.
bom não sou tão experiente, mas posso dar minha opnião.
te recomendo uma boa pesquisa mesmo assim.
webservice é um sistema de comunicação entre máquinas, independente de plataforma ou liinguagem de programação.
jms faz praticamente o mesmo, porem somente a linguagem java utiliza.
me corrijam se eu estiver errado.
[]´s
JMS é utilizado para serviços de mensageria. Assim como webservices, as filas de mensagem servem para integrar aplicações, independente da linguagem de programação. E aí existem várias formas de se utilizar mensagem (filas, tópicos)…
Também não sei muita coisa, mas é a noção que eu tenho… De qualquer forma, sugiro que pesquise para tirar suas próprias conclusões… Sorte na empreitada =)
Olá pcassiano,
Existem muitas diferenças e cada tem um cenário mais indicado para se utilizar. Podemos usar ambos em cenários de Integração ou Serviços.
As filas têm ótimo desempenho.
Em uma fila/tópico JMS você posta uma mensagem em qualquer formato XML ou texto e sem se preocupar restrição ao conteúdo. As filas normalmente são FIRE AND FORGET significa que você não se preocupa com a reposta, mas ainda assim é possível desenvolver filas com IN/OUT. As mensagens só são apagadas após a leitura de um consumidor, além disso, as filas podem ser persistidas mesmo que o servidor caia a garantias que a mensagem será mantida.
Os tópicos são filas que permitem n consumidores simultâneos.
As filas trabalham com JNDI.
Para você montar um cliente de fila/tópico só precisa indicar o servidor JMS e o nome do recurso do recurso JNDI.
As soluções de messageria se acoplam as filas dando características extras Logging, reprocessamento e validação. Além de filas JMS existem outras soluções de filas MQ Series, Oracle AQ e Tibco Rendezvous
Os serviços seguem uma arquitetura Request/Reply, um serviço contém n operações ligadas a um contexto de negócio. Como os serviços já estão associados à lógica de negócio possuem um contrato para restringir os valores e formatos do request.As validações de um contrato vão de Schema, Proxies, Schematron e outras dezenas de formas.
Os serviços podem ser assíncronos ou síncronos, se o cliente cair durante a execução de um serviço terá problemas.
A comunicação com serviços normalmente é feita via HTTP request (pode ser outro protocolo) através de um formato XML o SOAP, a desempenho fica irá depender da latência HTTP. Os serviços desenvolvidos em SOAP têm Payload grande, em analisadores de desempenho percebi que em média 30% a 40% da execução é gasto em parsing de dados.
Em ambos os casos há mecanismos de autenticação, os serviços podem utilizar o ws-s ou até mesmo autenticar via HTTP-BASIC.
Eu utilizo filas onde o volume de dados em uma mensagem é grande e não há necessidade se tratar a mensagem. Uso em casos de pequenas sincronias de dados, normalmente há pouca regra de negócio nesses cenários.
Já Serviços a opção na natural quando há regras de negócio associadas, para representar processos mais complexos acabo utilizando ferramentas para compor um processo como BPEL ou até BPMS.
Quando se costuma representar processos há cenários onde serão utilizadas as duas soluções.
Uma diferença importante é a questão de padronização. Em um Web Service você pode se comunicar utilizando o formato SOAP, assim, outra aplicação pode obter a descrição de seus objetos e se comunicar com você através do WSDL. Em JMS não, só você sabe o formato dos dados que está enviando, a estrutura desses dados não pode ser obtida através de um WSDL.
As diferenças técnicas já foram muito bem explicadas pelo companheiro ai 
[quote=xdraculax]Uma diferença importante é a questão de padronização. Em um Web Service você precisa se comunicar utilizando o formato SOAP, assim, outra aplicação pode obter a descrição de seus objetos e se comunicar com você através do WSDL. Em JMS não, só você sabe o formato dos dados que está enviando, a estrutura desses dados não pode ser obtida através de um WSDL.
[/quote]
Isso não é verdade, uma vez que você pode usar Rest Webservices sem a necessidade de mensagem SOAP
[quote=André Fonseca][quote=xdraculax]Uma diferença importante é a questão de padronização. Em um Web Service você precisa se comunicar utilizando o formato SOAP, assim, outra aplicação pode obter a descrição de seus objetos e se comunicar com você através do WSDL. Em JMS não, só você sabe o formato dos dados que está enviando, a estrutura desses dados não pode ser obtida através de um WSDL.
[/quote]
Isso não é verdade, uma vez que você pode usar Rest Webservices sem a necessidade de mensagem SOAP[/quote]
É verdade, mas estava me referindo somente a Web Services SOAP; pois não me tenho muita intimidade com REST. Coloquei agora como “PODE SER COMUNICAR”.
Aqui usamos JMS para comunicação entre vários agentes e uma central. Poderiamos até utilizar REST mas o JMS tem uma série de funcionalidades que são mais pertinentes para o tipo de aplicação em questão, como reenvio de mensagens, monitoramento das filas na central, e fila na central - assim a podemos receber 300 mil mensagens e processar a medida do possível em máquinas diferentes.
Acredito que tudo isso poderia ser feito em REST, mas demandaria um esforço de implementação muito maior.