Java EE Explorer: Enterprise messaging with JMS [Z]

Java EE in this issue of the EE Explorer (EE Pathfinder), developer and consultant Kyle Gabhart explains why messaging services are critical to the enterprise architecture, what types of barriers your solution must overcome, and In addition to the Java Messaging Service, JMS, what alternative solutions are available. At the end of this article, he analyzed three available solutions (simple JMS Client, session Bean combined with JMS, and message-driven beans), and provided certain guidelines to measure these options.
When it comes to choosing a messaging solution, you can find a solution that fits your business like a glove. Your messaging framework must be able to communicate between a set of applications and enterprise resources. Furthermore, the messaging framework must accomplish this task quickly and reliably. In addition, it must be seamless in the face of day-to-day harassment and emergencies.

To choose the right messaging solution based on your needs, you should first have a clear understanding of your organization's current composition and future trends. In addition, the choice of solutions will be helpful if you have a thorough understanding of the obstacles that the messaging framework must overcome in accomplishing the goals. Finally, you need to know what you can choose from: What technologies are available, and how the various technologies apply to different environments and requirements.

In this issue of the Java EE explorers, we will elaborate on the above points. The first is an overview of enterprise messaging, where we will look at the role that messaging plays in your organization and give you some challenges in building reliable communications. Next, we will take a quick look at the architectural perspective, in a typical enterprise network environment, the Java-EE message delivery technology and message-oriented middleware work together. We will then start a more specific discussion of the messaging packages for Java messaging Services (Java Message Service, JMS), and EE. We will discuss the basic goals and functionality of the three types of Java EE messaging clients, and you can learn about the strengths and weaknesses of each type of Java EE messaging client. Finally, we will analyze some of the common messaging scenarios and solutions that will help you choose the best Java Messaging solution for your business.

Enterprise Message Delivery 101

The Enterprise Messaging Framework is designed to enable one or more applications to overcome various obstacles for communication. Common barriers include the need for two systems to run simultaneously (synchronous communication), the need for multiple applications to obtain the same message (multiple transmissions), most systems are heterogeneous, and network failures.

M many enterprise architectures rely on message-oriented middleware systems (MOM) to provide message channels for different types of systems. MOM provides a common, reliable way for applications to easily create, exchange, and process messages without having to consider the implementation details of messaging clients. Messages are sent to server destinations and domains (domain), not to physical addresses. A messaging client simply declares interest in a particular domain and destination, provides the appropriate security token (token) to gain access to the domain, and then interacts with the messaging server through that destination.

Conceptually, this is no different from the way real-life messages are delivered. The sender of the message is solely responsible for using the correct packaging, providing the correct address and attaching the appropriate postage. The Post office (here is a mom system) handles all issues related to the safe and reliable delivery of messages, regardless of any obstacles appearing in front of them (machine failure, bad weather, etc.).

In a MOM system, the coupling between clients is weaker, which allows them to maintain the best quality of the service without actually "online" all day. If you can remove the requirement that applications are always available, then maintenance and scalability will become easier to manage. Can be applied offline at any time of the day, updating the application, or refreshing the application as routine maintenance without worrying about the quality of the service.

Java Messaging Service

The MOM server allows different types of systems to exchange messages, but each MOM vendor has its own API for handling messages. This lack of standardization is not acceptable for Java technology development paradigms. To make the most of the existing MOM infrastructure, while standardizing, the Java EE platform provides JMS.

Java standardization
To provide platform-independent and vendor-independent solutions, all Java technologies can be divided into two parts:

A specification of a (or set) definition of the technology that identifies the objectives and responsibilities of the developer and the tool vendor that implements the technology.

A set of neutral interfaces that serve as a contract between application developers and tool vendors.
Regardless of the Java technology you are using, you first write the application components that use the interfaces provided in the technical specification, and then provide a specific vendor's implementation of those interfaces at run time. In Java EE, the specification and API for enterprise messaging is JMS.



JMS defines the rules for passing messages in the Java Enterprise system and declares some interfaces that facilitate the exchange of messages between the application component and the messaging system (usually MOM). The JMS client opens the connection to the destination on the MOM server, and then sends and receives messages on that destination. JMS removes the burden of guaranteed delivery (guaranteed delivery), message notification (messages notification), message durability (messages durability), and all underlying network and routing problems in the messaging system. JMS and MOM work well together because they all make a clear distinction between messaging clients and servers.

Type of message delivery

JMS supports two basic message-passing mechanisms. The first mechanism is point-to-point messaging (point-to-point messaging), in which the message is sent by a publisher (the sender) and is received by the Subscriber (the receiving party). Another mechanism is publish-subscribe message passing (publish-subscribe messaging), in which messages are sent by one or more publishers, and received by one or more subscribers. Although these two mechanisms are the real basis for JMS, many people still look at the technology in terms of three messaging models:

One-to-one message passing (one-to-one messaging) is a point-to-point model. Messages are sent by a JMS client (publisher) to a destination on the server (queue). Another JMS client (subscriber) can access the queue and get the message from the server. Multiple messages can be stored in the queue, but only one message at a time is available.

One-to-many Message Passing (one-to-many messaging) is a publish-subscribe model. It is still a JMS client that publishes a message to a destination on the server, but this time the destination is called a Theme (topic). The key difference here is that the message in a topic includes a parameter that defines the durability of the message (how long it can wait for subscribers on the server). The message will remain in the subject until all subscribers to the topic have taken a copy of the message, or the message's durability time has expired, regardless of which of the above, the message will be removed from this topic.

Many-to-many Messaging (many-to-many messaging), which is also a publish-subscribe model, and extends a one-to-many message-passing model. In addition to supporting multiple subscribers, the model also supports a topic with multiple publishers. A good example of multiple messaging is the e-mail listserve: Multiple publishers can post multiple messages to a topic, and all Subscribers will get each message.
The structure of a JMS message is fairly straightforward. One of the sections (section) is used for routing, addressing, and message recognition; there is also an optional section where you can pass some application-specific (application-specific) parameters, and the third part holds the payload of the message (text, Bytes, Value map, objects, and so on. These three sections are called headers, properties, and bodies, as shown in Figure 1.

Figure 1. JMS message Structure


The type of messaging model you use depends on the needs of your business. It is not uncommon to use more than one messaging strategy in an enterprise at the same time. In later sections, we'll look at three JMS solutions for the Java platform: simple JMS clients, combined with session beans for JMS, and message-driven beans. We will revisit each type, their respective strengths and weaknesses, and their applicability to different enterprise scenarios.

Simple JMS Client
Although JMS is an enterprise-class technology released with Java 2 Enterprise Edition, you can easily convert a standard Java client into a JMS-enabled application. Adding enterprise messaging functionality to Java applets, command-line applications, swing applications, or Java Webstart is simple. You simply add a few method calls to the J2SE application code, and then add a jar file that contains the interface and implementation class of Jndi (which is also part of the Java EE) to the classpath (classpath). If you have loaded the jar file on the client and added it to your application's classpath, you can use Jndi to access the JMS provider (see Resources below for a link to more information about JMS messaging).

Advantages and disadvantages of simple JMS clients
The simple JMS client approach has many advantages, the most obvious of which is its simplicity and universality. All J2SE applications can be easily extended to interact with a JMS messaging system. In addition, new applications using JMS are deployed with little or no configuration to the client. A simple JMS client is a simple, flexible, lightweight extension of almost any Java architecture.

On the negative side, we are confronted with issues such as security, transaction processing, and scalability. For a simple JMS client, you can only choose to outsource security and transactions to a vendor, i.e., these issues will be handled in a vendor-specific manner. If your simple JMS client handles incoming messages and sends messages, you will encounter scalability problems. JMS does not have the built-in mechanism to handle more than one incoming request at a time. To support concurrent requests, you need to extend the JMS client to produce multiple threads, or to start multiple instances of the JVM, so that the threads or instances run their applications. In addition, you need to configure the JMS provider to have multiple subscribers on some appropriate destinations. At this point, you (or your development team) will question whether a simple JMS client solution is really simple.

Session Bean and JMS
Combining session Beans with JMS is a viable enterprise-oriented solution. The session Bean is designed to fulfill requests for business services. An enterprise messaging system must be queried to fulfill such a request, in which case the enterprise messaging system can be accessed transparently by a session bean. Using the session bean as a JMS client also allows the integration of JMS traffic into the context of a large enterprise transaction. For example, you could create a Java EE transaction to get a message from a JMS provider, extract the data from the message, and try to update the database. If the update operation fails and the transaction is rolled back (rollback), a message is sent to the JMS provider on a separate destination, along with a description of why the transaction failed.

Enterprise JavaBeans Technology uses the resource manager to connect factories to access additional container (extra-container) resources. These resources are standard enterprise components, but they are not a core part of the Java container, they include data sources, JMS sessions, javamail sessions, URL connections, and the Java-based Connector architecture (Java Connector Architecture, JCA) adapters. A resource manager is a component of the Java EE container that manages the entire lifecycle of a particular type of resource, including connection pooling, transaction support, and any network protocols necessary to implement a physical connection.

The enterprise Bean uses three steps to obtain a connection to a JMS session: A connection factory reference is obtained through a jndi lookup, a connection is obtained through a factory reference, and then a topic or queue Connection object is used in a regular JMS manner. Because JMS must have the support of an application server that complies with the Java EE specification, additional libraries or components are no longer required.

Advantages and disadvantages of a JMS session bean
Combining JMS and session beans is a step forward in enterprise functionality and a setback in simplicity and flexibility. By using session beans, application developers can access the entire range of Java EE features provided by the EJB container, including Jndi, declarative transaction semantics, automatic concurrency support, resource management, declarative security, and for entities such as the entity bean, data source, Access to enterprise resources, such as JavaMail and JCA adapters. From a message-passing standpoint (unlike an MDB), the session Bean's collaboration with JMS does not impose any number of restrictions on the topics and queues that your beans can access.

As a price for enhancing enterprise features, you sacrifice simplicity, and the client footprint (the clients footprint) is no longer as small as it used to be, and there is no asynchrony. There's nothing strange about the first two losses. If you've been focusing on the Seeker series for a while, you'll be better able to understand that. Session beans require a mature Java EE EJB container, which is a heavy burden for your development team (for EJB development) and your entire system architecture (for client footprint).

Asynchrony is one of the main advantages of using enterprise messaging technology like JMS, and it has not lost anything while gaining that advantage. With JMS, a messaging client can send a message through the provider, and the message can be taken offline after it is sent out, allowing the provider to send the message calmly. A client that receives a message can periodically line up and check for new messages, or it can set up a listener component that remains online to wait for messages from the provider. The session bean is synchronized and cannot support the always online (always-on) listener component. Unlike the previous client, a synchronized Java client must invoke a session bean method. The session Bean method then opens a connection to a message-passing provider to send and receive messages.

Message-driven beans
The EJB 2.0 specification defines a new enterprise bean to compensate for the deficiencies of four other types of enterprise beans (two session beans and two entity beans). The new bean is the message-driven bean (Message-driven bean,mdb), which is expected to provide a reusable messaging component to leverage existing investments in the Java EE Application Server, especially with existing EJB technologies.

An MDB can only be invoked asynchronously through a JMS message. Therefore, it does not have the local and remote interfaces that other beans have. Instead, the MDB implements two special interfaces: an interface to the EJB container (Javax.ejb.MessageDrivenBean), and a messaging interface (Javax.jms.MessageListener). As a sophisticated JMS client, an MDB can send messages and receive messages through a MOM server. As a business Bean,mdb is managed by a container, and declarative configuration is performed through an EJB deployment descriptor.

Advantages and disadvantages of MDB
MDB allows developers to take advantage of existing investments in EJB technology, but can still consolidate these investments into an asynchronous messaging context. For example, a JMS client can send a message to an MDB that has been waiting online for a message to come in, while the latter can access a session bean or some entity bean. In this way, an MDB can be used as an asynchronous wrapper to provide access to business processes that can only be accessed through a synchronized rmi/iiop.

The message-driven bean itself is also a powerful messaging solution. Because the MDB is specifically designed to be a consumer of messages and is still managed by the EJB container, they provide a great advantage in scalability. Because the message beans are stateless and managed by the container, they send and receive messages concurrently (the container simply raises another bean from the pool). This, coupled with the inherent scalability of the EJB application server, constitutes an extremely robust, scalable enterprise messaging solution.

On the other hand, an MDB is a relatively new thing, not a lot of testing. As a result, not all Java EE vendors support them, and even those vendors that support MDB are only recently implementing them. It can be foreseen that the immaturity of the MDB means that the supplier has a long way to go in terms of stability and reliability. Also, the MDB community needs to undergo more tempering to get a set of best practices for the use of MDB.

Aside from the relative immaturity of the MDB, it is important to understand that it is designed for a specific purpose (that is, as a consumer of JMS messages). An MDB can only be invoked through a JMS message, not in any other way. This means that they are ideal for consumers of messages, but not necessarily for the producers of messages. The message-driven bean can, of course, send a message, but only if it wants to call it first by passing in a request. Also, the currently designed MDB can only be mapped to a single destination. They can only listen for messages on that destination. This limit can be changed in later versions, but you can now define an MDB for each destination you want to listen to.

Message Delivery Solution Guidelines
As mentioned earlier, most of the work you can do when choosing the right solution is to measure your business's specific needs, including current requirements and foreseeable future needs. It would also be helpful to remember that multiple enterprise messaging solutions can be used in combination. In the next section, we'll look at some common messaging scenarios and potential JMS solutions for each scenario. These can provide general guidelines when you choose the right messaging technology for your business, or if you mix multiple technologies.

Access multiple topics and queues from one component
If your business process stipulates that a message destination can only be accessed conditionally (in other words, if you x<5, you access topic A, and if you x>5, you will not be able to use the MDB). However, you can use a simple JMS client or combine the session bean with JMS. To make a decision between the two options, you must have lightweight features for simple JMS clients (especially for applets, swing applications, and stand-alone console applications) and the robustness of the Java EE container (including transparent transactional support, Tradeoff between declarative security and other EJB resource management capabilities.

accessing session beans and entity beans asynchronously
There are two ways to handle this scenario. A more obvious way is to use a message-driven bean, but only if your vendor supports MDB technology. The MDB is designed to consume asynchronous messages and to access enterprise functionality on behalf of the sender of the message. In addition, the application server can maintain multiple instances of an MDB to handle concurrent service requests. If you cannot use an MDB, you can create a simple JMS client to act as a listener. When a message is received, the client can establish a synchronized RMI connection with the application server and invoke the session bean or entity bean in the usual way. However, an MDB is a more recommended solution.

Build as thin a JMS client as possible
In this context, a simple JMS client is clearly a winner. Simple JMS is the right choice if it's more important for you to provide a lightweight messaging client than to have the scalability and robustness of a Java-EE client like a session bean. Whether it's a combination of session beans and JMS, or an MDB, both require a Java EE application Server, which makes both choices unsuitable for thin client implementations.

Send and receive messages concurrently
The only appropriate option here is to use the message-driven bean. Message-driven beans are specifically tailored for this scenario. Technically, simple JMS clients can also use multithreaded technology to provide similar support, but the solution is complex to develop, and the last thing developed is not very scalable.

Merging message delivery into the Java EE process
You may have invested in the Java EE Architecture and recognized the need to incorporate enterprise messaging into these Java EE processes. In most cases, your best solution is to use the session bean in conjunction with a JMS resource connection. You can use an existing session bean to access one or more topics and queues without rebuilding the entire infrastructure. These session beans will continue to perform the traditional requests for business services, and also assume the task of messaging. In some cases, it is good to expose your existing business services to a JMS client, as you can see from the previous discussion.

Conclusion
Messaging is an exciting and increasingly popular solution for today's diversity and increasingly asynchronous nature of technology prospects. The Java Messaging Service provides a vendor-and platform-independent medium to tie together multiple systems by using enterprise messaging. In this article, we have a brief overview of enterprise messaging and JMS, and provide guidelines to help you choose the solution that best suits your organization.