Architecture

La figure suivante illustre l'architecture UMS de base :

Figure 1–1 Architecture UMS

Le service UMS, qui s'exécute sur un serveur Web, est un langage neutre et indépendant de la plate-forme. Le service UMS sert de pont entre une application cliente non JMS et un fournisseur JMS. Il reçoit les messages envoyés via l'API UMS, les transforme en messages JMS, puis les envoie aux différentes destinations dans le fournisseur JMS par le biais du protocole natif du fournisseur. De même, il extrait les messages des destinations du fournisseur JMS, les transforme en texte ou en messages SOAP, puis envoie les messages aux clients non JMS comme demandé par les clients via l'API UMS.

L'API UMS, basée sur un protocole simple, non dépendant d'un langage, prend en charge les applications basées sur le Web et non basées sur le Web, et peut être utilisée avec les langages de script et de programmation. L'API est proposée dans deux styles : une API de messagerie simple qui utilise un protocole de type REST (Representational State Transfer) et une API de messagerie XML qui incorpore le protocole dans les en-têtes de messages SOAP. Dans les deux cas, cependant, l'API ne requiert qu'une seule requête http pour envoyer ou recevoir un message.

La simplicité et la flexibilité de l'API UMS signifie que AJAX, .NET, Python, C, Java et bien d'autres applications peuvent envoyer un message texte et/ou des messages SOAP (avec pièce jointe) aux destinations JMS ou recevoir de messages de destinations JMS. Par exemple, les applications Python peuvent communiquer avec les applications .NET, les applications iPhone avec les applications Java, etc.

Pour Message Queue 4.3, le service UMS prend uniquement en charge Message Queue en tant que fournisseur JMS.