mq5.1-source.src.share.java.webapps.ums.umsIntro.html Maven / Gradle / Ivy
Universal
Message Service (UMS)
Message
Queue 4.3 introduces a new universal messaging service (UMS) and
messaging API that provides access to Message Queue from any
http-enabled device. As a result, almost any application can
communicate with any other application and benefit from the
reliability and guaranteed delivery of JMS messaging. In addition,
the UMS provides enhanced scalability for JMS messaging, allowing the
number of messaging clients to reach internet-scale proportions.
Architecture
The
basic UMS architecture is shown in the following figure:
The
UMS, which runs in a web server, is language neutral and platform
independent. The UMS serves as a gateway between any non-JMS client
application and a JMS provider. It receives messages sent using the
UMS API, transforms them into JMS messages, and produces them to
destinations in the JMS provider by way of the provider's native
protocol. Similarly, it retrieves messages from destinations in the
JMS provider, transforms them into text or SOAP messages, and sends
the messages to non-JMS clients as requested by the clients through
the UMS API.
The
simple, language-independent, protocol-based UMS API supports both
web-based and non-web-based applications, and can be used with both
scripting and programming languages. The API is offered in two
styles: a simple messaging API, and an XML messaging API that embeds
the protocol in a SOAP message header. In both cases, however, the
API requires only a single http request to send or receive a message.
The
simplicity and flexibility of the UMS API means that AJAX, .NET,
Python, C, Java, and many other applications can send text message
and/or SOAP (with attachment) messages to JMS destinations or receive
messages from JMS destinations. For example, Python applications can
communicate with .NET applications, iPhone can communicate with Java
applications, and so forth.
For
Message Queue 4.3, the UMS supports only Message Queue as a JMS
provider.
Additional
Features
The
UMS serves as more than the simple gateway described above. It
supports stateful as well as stateless client sessions. If requested
by the client, the UMS will maintain session state for the client
application across multiple service requests. The UMS can use
container-managed authentication, or be configured to authenticate
clients with the Message Queue broker, or both. The UMS also supports
transactions, enabling client applications to commit or roll back
multiple service requests as a single atomic unit.
Because
the UMS can support a large number of clients on a single connection
to the Message Queue broker, it eases the load on the broker's
connection services, allowing for maximum scalability. In addition,
UMS capacity can be increased by horizontal scaling, allowing for
internet-scale messaging loads.
On
the client side, because of the simplicity of the protocol-based UMS
API, no client libraries are required. As a result, the API can be
extended in the future to implement additional JMS features without
any need to upgrade client applications.
Using
the UMS
To
use the UMS, you deploy the UMS into a web container that supports
Servlet 2.4 or later specifications, start the Message Queue broker,
create the appropriate destinations, and write a messaging
application that uses the UMS API to send or receive messages.
The
UMS imqums.war file, contained in the Message Queue 4.3 distribution,
is installed in the following location, depending on platform:
Platform
Location of imqums.war
Solaris
/usr/share/lib/imq
Linux
/opt/sun/mq/share/lib
AIX
IMQ_HOME/lib
Windows
IMQ_HOME\lib
You
can rename the .war file as appropriate.
For
information on configuring the UMS, see (./config.html)
For
documentation of the UMS API, see (./protocol.html).
For
programming examples in several languages, see
(./examples/README.html)