Java theory and Practice: Should you use JMS in the next enterprise application?

In recent years, developers have been able to get more extensive enterprise Message Queuing (MQ) products. Proper use of MQ technology can often improve the organization, performance, and scalability of your application. The Java Messaging Service (JMS) is part of the integration into Java EE, which enables MQ services to be used by any Java EE application. In this article (also the first part of this column series), Brian outlines some of the benefits of using Message Queuing in Java applications and explores the types of issues that can benefit most from MQ technology. Share your thoughts on this article with the author and other readers on the forum (or by clicking the discussion at the top or bottom of this article).

Message Queuing (MQ) tools are not known or understood by database tools (such as a relational (SQL) database), and database tools are key components in almost all enterprise applications and a large number of relatively simple applications. Developers can always take multiple types of data products, ranging from a cheap database that can only be used on a desktop (such as dBase or Microsoft Access) to a Working Group database server (for example, Sybase sql/anywhere). Then to the Enterprise database server (for example, DB2 or Oracle). No matter what your project looks like, there's always a database product that's affordable, performance, and functionality that you can use.

Like databases, MQ products are sometimes referred to as message-oriented middleware (MOM) for quite some time. Until recently, however, MQ servers had been the high-end product of expensive enterprise developers who could only be the most well-funded. As a result, only a very small number of developers can enjoy the benefits of using messaging in their applications.

Popular Message Queuing

Fortunately, the situation is beginning to change; there are already several low price MQ servers on the market. In 1997, Microsoft released MSMQ, a transactional Message Queuing product, as an integrated part of Windows NT Server-without additional licensing costs. Sun has included the JMS APIs in the original Java EE specification, which has greatly facilitated the popularity of message delivery. In version 1.3 of the Java EE specification, all Java EE containers require the inclusion of a JMS provider (provider).

JMS, the Java Messaging Service, is an API that allows Java applications to access a wide range of MQ servers through a standardized interface (or, according to JMS, a provider), just as JDBC allows programs to access many different database servers through a common interface. Most Java EE containers contain JMS providers; In the future, all Java EE containers will contain JMS providers. There are no Java-ee containers to use JMS; there are several separate JMS provider implementations on the market. In addition, the EJB 2.0 specification introduces a new type of EJB-message driven bean― that makes it easy to create message-driven components that take advantage of entity and session beans.

Now that we can all use the JMS service, we should learn the ability to use messaging in our applications. Willy Farrell is an IBM E-commerce architect who has written an excellent introductory tutorial on using JMS (see Resources). It involves the basics of creating messages and queues, as well as all the options for prioritizing messages, retrieving messages, and encoding messages.

Messaging and databases complement each other, and in many cases, using messaging and relational databases can produce a much better solution than just using them.

Historically, MQ servers have been used for event-oriented applications, such as financial services applications, or as a way to interoperate with disparate systems (such as connecting disparate database applications or connecting an enterprise to another enterprise in a supply chain network). The term "message-oriented middleware" is often applied to MQ servers, emphasizing that the main purpose of MQ technology is to connect disparate systems. However, as the cost of MQ products is reduced, many other applications can now benefit from Message Queuing.

What does an MQ server do?

In MQ parlance, the message is just a byte stream (this byte stream can be an XML document, a serialized Java object, a text string, or even an empty message). The interpretation of the message is left to the application domain, and the MQ infrastructure does not impose any semantic and structural restrictions on the message. Messages are stored in queues, and MQ servers allow you to add messages to queues and to take messages out of queues.

So far, Message Queuing sounds like a simple list. This is true in its simplest form, but an enterprise MQ server enhances its functionality by encapsulating some feature features into this list management:

Security that controls who can write to the queue and who can read from the queue

Network interface, which allows message producers and consumers to be located in different places

Transactional support so that both team and outbound operations have transactional attributes: atomicity, consistency, isolation, and durability

Distributed transaction support so that queue operations can participate in distributed transactions with other resource managers, such as SQL databases

Persistent storage

Load Balancing

Failover

Management