Architektur

Die grundlegende UMS-Architektur wird in der folgenden Abbildung gezeigt:

Abbildung 1–1 UMS-Architektur

Der UMS, der auf einem Webserver ausgeführt wird, ist sprachneutral und plattformunabhängig. Der UMS dient als Schnittstelle zwischen einer Client-Anwendung ohne JMS und einem JMS-Provider. Er empfängt Meldungen, die mithilfe der UMS-API versendet werden, wandelt sie in JMS-Meldungen um und erzeugt sie am Ziel im JMS-Provider mithilfe des nativen Protokolls des Providers. Ebenso empfängt er Nachrichten von den Zielen im JMS-Provider, wandelt sie in Text oder SOAP-Nachrichten um und sendet sie entsprechend den über die UMS-API angegebenen Anforderungen an Clients ohne JMS.

Die einfache, sprachunabhängige, protokollbasierte UMS-API unterstützt sowohl webbasierte als auch nicht webbasierte Anwendungen und kann mit Skript- und Programmiersprachen verwendet werden. Die API wird in zwei Stilen angeboten: als einfache Messaging-API, die ein Protokoll des Typs Representational State Transfer (REST) verwendet, und als XML-Messaging-API, die das Protokoll in einen SOAP-Nachrichten-Header einbettet. In beiden Fällen erfordert jedoch die API nur eine einfache HTTP-Anforderung zum Senden oder Empfangen einer Nachricht.

Die Einfachheit und Flexibilität der UMS-API bedeutet, dass AJAX, .NET, Python, C, Java und viele andere Anwendungen Textnachrichten und/oder SOAP-Nachrichten (mit Anhang) an JMS-Ziele senden oder von JMS-Zielen empfangen können. Beispielsweise können Python-Anwendungen mit .NET-Anwendungen, das iPhone mit Java-Anwendungen usw. kommunizieren.

Für Message Queue 4.3 unterstützt der UMS nur Message Queue als JMS-Provider.