Java Message Service (JMS) FAQ From jGuru
What is JMS?
Java Message Service (JMS) is a specification for message passing and related operations among distributed software components. JMS vendors implement the specification, providing the requisite API library, plus a broker, or server, that handles message passing among clients. Programmers then implement applications that communicate with each other by way of the vendor's JMS software.
What is message passing?
Message passing is a general term for a variety of strategies for high-level, structured interclient communication. For example, a mobile agent framework could provide classes and methods with which two agents (on two different computers) send each other messages. The steps required to send and receive messages are specific to the framework. JMS supports two common message passing strategies, namely, point-to-point and publish/subscribe. JMS can be utilized by any (Java-based) distributed software components; of course, the JMS middleware must be available.
Are there other messaging frameworks that use Java technology?
Yes. Prior to JMS, Java software for various distributed computing environments, for example, the WebLogic server, the Aglet framework for mobile agents, SoftWired's iBus software, and many others have provided a variety of message-oriented, interclient communication solutions for enterprise computing. In many cases, the messaging functionality is part of a larger distributed computing framework.
Why is JMS important?
There are several reasons. First, the JMS specification includes two popular messaging strategies: point-to-point and publish/subscribe. Many vendors are supporting this common framework; hence, programmers will be able to implement message-oriented operations in their distributed software that will be portable across many messaging-oriented middleware (MOM) products.
Second, JMS supports both synchronous and asynchronous message passing. In some scenarios, asynchronous messaging is essentially required; in others, it is simply more convenient than synchronous message operations; and, in general, there are scenarios for which highly structured, synchronous communication, such as remote method invocations, is just too rigid.
A third important issue is that JMS supports an event-oriented approach to message reception; event-driven programming is now widely recognized as a productive programming paradigm with which many programmers are now quite familiar.
Fourth, although the JMS specification does not require a security-related API, many JMS implementations provide extensive built-in security. Messages can be transmitted using certificates, as well as encryption. JMS implementations free the developer from many security burdens associated with distributed computing because JMS applications work through the JMS server, which provides security through administered objects. That is, beyond the application, it's possible to establish topic- and queue-based security controls for users, groups, access lists, and so on.
Where would I use JMS software?
JMS-based communication is a potential solution in any distributed computing scenario in which you need to pass data, either synchronously or asynchronously, among distributed software components. A distributed component can subscribe to specific topics, or connect to specific queues, and then act accordingly when qualifying messages arrive.
JMS can be an important tool for both e-commerce and e-business applications. Any enterprise computing strategy that calls for middleware solutions that function as glue and/or communication pathways among legacy applications is a potential candidate for JMS-based distributed software components. It is straightforward to write distributed components, for example, Enterprise JavaBeans that interface with legacy applications. These legacy-software-managing Enterprise JavaBeans can send legacy-related data among themselves via JMS middleware.
What is the role of the JMS server? Why is it necessary?
The server, message broker, or whatever it is called, functions as an intermediary. Suppose a distributed component wants to send (financial) stock information to one or more remotely located distributed components. Rather than having to know the exact clients to which it sends messages containing stock information, it can establish either a message queue or a message topic area (depending on the message-passing scheme, point-to-point or publish/subscribe) with the JMS server and "post" the stock information with the server, which then distributes the messages to the appropriately registered receiving clients.
Also, without this intermediary, the sending client would have the burden of monitoring whether or not the receiving client is currently connected, whether or not a network failure occurred during the send operation, and so on. The server plays an important role in transparently handling many network-related issues, including reliable message delivery, which can require transaction processing and/or persistent message storage.
Does JMS provide load balancing, fault tolerance, scalability, and so on?
The JMS specification does not address these issues; hence, vendors are free to implement their own support, and many vendors do provide these services.
What else is missing from JMS?!
The answer depends on your point of view. From one point of view, nothing is missing. In terms of common distributed computing-related functionality, typically present in larger Java application servers, JMS does not mandate functionality related to the following:
· Error, or system event, notification
· Load balancing, scalability
· Low-level transport protocol
What software do I need in order to add JMS message passing to my enterprise's existing distributed applications?
The "J" in JMS stands for Java, so the first prerequisite is a Java development and runtime environment.
The second prerequisite is Java-based distributed applications, as opposed to C++/CORBA applications. Examples include applications developed using the distributed computing framework that accompanies popular Java application servers such as Gemstone/J, ObjectSpace's Voyager, the WebLogic server, and others. EJB applications are, of course, distributed applications. Enterprise JavaBeans are often deployed in EJB-only servers, or in EJB-capable Java application servers.
Third, if not provided by the existing distributed computing software, you must have a JMS implementation. Note that some Java application servers include JMS; hence, they provide virtually seamless access to JMS functionality.
Is it possible to develop distributed applications with JMS alone? Is it necessary to have a Java application server, EJB server, and so on?
Yes. No. Minimally, a computing task can be distributed among two or more Java applications that interoperate by sending and receiving data via JMS. Thus, the minimal JMS-ready environment includes a Java development and/or runtime environment plus JMS middleware.
And, of course, distributed applications can use JMS message passing directly, or develop a higher-level, enterprise-specific framework on top of JMS.
What is point-to-point messaging?
With point-to-point message passing the sending application/client establishes a named message queue in the JMS broker/server and sends messages to this queue. The receiving client registers with the broker to receive messages posted to this queue. There is a one-to-one relationship between the sending and receiving clients.
What is publish/subscribe messaging?
With publish/subscribe message passing the sending application/client establishes a named topic in the JMS broker/server and publishes messages to this queue. The receiving clients register (specifically, subscribe) via the broker to messages by topic; every subscriber to a topic receives each message published to that topic. There is a one-to-many relationship between the publishing client and the subscribing clients.
How does JMS compare to peer-to-peer distributed computing?
The term peer-to-peer is used in a variety of ways in distributed and network computing. One usage, at the application level, is to describe a distributed application scenario in with each distributed component potentially interacts with every other distributed component and maintains a network reference (access) to each component (using any of several mechanisms to do so, for example, via Enterprise JavaBeans and EJB servers resident on each network host, via simple RMI-based communication among applications, and so on).
With JMS, distributed components interact with the JMS broker via destinations (topics and queues), which then disseminates messages to the registered clients; thus, distributed components do not have to know (and manage) each others' network locations. As for the JMS middleware, it can use (behind the scenes) any of several network topologies, for example, bus, ring, hierarchical, fully connected (peer-to-peer), star (hub-and-spoke), or others, including hybrids.
Messaging systems are peer-to-peer distributed systems in the sense that, at least potentially, every (registered) client can communicate with every other (registered) client.
What are the core JMS-related objects required for each JMS-enabled application?
Each JMS-enabled client must establish the following:
· A connection object provided by the JMS server (the message broker)
· Within a connection, one or more sessions, which provide a context for message sending and receiving
· Within a session, either a queue or topic object representing the destination (the message staging area) within the message broker
· Within a session, the appropriate sender or publisher or receiver or subscriber object (depending on whether the client is a message producer or consumer and uses a point-to-point or publish/subscribe strategy, respectively)
· Within a session, a message object (to send or to receive)
What are JMS messages?
JMS messages implement the Message interface.
JMS messages include a header, properties, and the message body. Headers provide identifying and routing information. Properties allow arbitrary ornamenting of messages with application-specific markers or tags. Receiving clients can select, or filter, messages based on properties.
The message body is available in five flavors:
· StreamMessage - a stream of Java primitive values
· MapMessage - a set of name-value pairs
· TextMessage - a String object
· ObjectMessage - a serialzed Java object
· BytesMessage - a stream of uninterpreted bytes
To obtain a message of the requisite type, make a request via the appropriate create method, for example:
TextMessage message = session.createTextMessage();
Note that some vendors provide additional message types.