Service Web: un service invocable conforme aux normes, peut être écrit en Java, peut être écrit dans une autre technologie, par ex. .NET. Le point clé est qu'il existe un langage standard, WSDL, qui décrit le service. Le WSDL contient des informations sur le transport, le protocole, l'endroit où le service s'exécute, les opérations disponibles et les charges utiles qui circulent.
La plupart des services Web que vous rencontrerez utiliseront des messages SOAP (un format XML particulier) sur un protocole HTTP, et le WSDL contiendra donc l'URL de l'endroit où appeler le service. Plus généralement, d'autres formats et protocoles de messages sont possibles - nous reviendrons sur ce point dans un instant. Supposons que vous ayez le WSDL pour un service que vous souhaitez appeler à partir d'un programme Java. En principe, vous pouvez écrire Java pour formater une charge utile XML appropriée et injecter le message sur une connexion HTTP. Parfaitement faisable, mais très fastidieux, presque tout le code est du code standard, qui peut être généré à partir du WSDL. De même, si vous voulez créer un service Web en Java, vous pouvez commencer par écrire le WSDL, mais encore une fois il y a beaucoup de code standard pour lire HTTP, analyser XML, etc. Dans les deux cas, vous bénéficiez de standards API Java pour faire tout ce travail. Il y en a eu plusieurs, JAX/RPC et JAX/WS en sont deux, et JAX/WS est le plus récent et le plus facile à utiliser. Une autre technologie d'intégration consiste à utiliser la messagerie, de nombreux fournisseurs proposent des produits de mise en file d'attente des messages, il est donc parfaitement possible d'envoyer des messages de (disons) Java à C++, il suffit de se mettre d'accord sur le format du message (pas de WSDL standard pour vous le dire).
JMS est une API de programmation Java qui fournit une abstraction sur les produits de messagerie des fournisseurs spécifiques. Si vous travaillez en Java, JMS vous offre la portabilité entre les produits de messagerie. La norme Java EE exige que les fournisseurs de Java EE App Server fournissent une infrastructure de messagerie. Je crois que lorsque les systèmes d'entreprise prennent de l'ampleur, ils ont presque toujours besoin de fonctions de messagerie asynchrones.
Il existe différentes possibilités d'appliquer des approches de type WSDL à la messagerie. Par exemple, il est possible d'écrire un service Web en utilisant SOAP/JMS plutôt que SOAP/HTTP. JAXM est une API émergente dans cet espace. Franchement, je ne suis pas clair quant à sa relation avec SOAP/JMS et les normes telles que WS-ReliableMessaging.
Merci. Votre explication a beaucoup aidé. En outre, j'ai lu que la différence clé entre JMS et JAXM est que JMS est haute performance, faible latence alors que JAXM est simple et fiable. Je n'ai pas compris la différence de "fiabilité", bien que JMS avec MDB semble fiable. – Nithin
JMS et JAXM ne sont que des API. Ils peuvent être implémentés par de nombreux produits de messagerie différents. Les fournisseurs de messagerie sérieuse tels qu'IBM et TibCo disposent de systèmes de messagerie performants et fiables, avec des API JMS. Le point de vente intrinsèque de JAXM ne peut être la fiabilité ou la performance. – djna