Chapter 8. TIBCO Enterprise Message Service™

The TIBCO Enterprise Message Service™ (EMS) product plays two important roles in TIBCO-based designs. One is as an application-level messaging transport, and the other is as the internal application-level communications infrastructure underlying the TIBCO ActiveMatrix Service Bus. Consequently, it is important for an architect to have some familiarity with this product.

Most of the required familiarity with EMS can be acquired through the supplied product documentation. The information presented here is intended merely to provide an overview of the product. For further information, the reader should consult the technical documentation supplied with the product.

Enterprise Message Service™ Product Structure

The Enterprise Message Service product comprises a number of components (Figure 8-1). At its heart, the workhorse component is the EMS server, an operating system executable that manages the distribution of messages between clients. This server, depending on configuration, can store messages in transit in either a file or a database. Designs involving EMS often employ multiple EMS servers for fault tolerance or load distribution.

Figure 8-1. TIBCO EMS Components

The EMS server is implemented in the C programming language for efficiency. It is important to note that the bulk of the work being performed in the EMS server occurs in two threads, one handling the network I/O and the other interacting with the files or databases used for message persistence. Since the bulk of the work occurs in these two threads, a single EMS server instance will consume little more than two CPU cores when fully loaded.

Companion to the EMS server component are the EMS client libraries provided for the Java, C, C#, .NET, and COBOL programming languages. These libraries provide the facilities for interacting with the EMS server and are incorporated into clients who wish to send and receive messages. The API provided by the EMS Java client library conforms to the Java Messaging Service (JMS) 1.1 specification.¹

With respect to administration, there are a number of possible approaches. The server itself provides administrative APIs that are accessible from both the Java and .NET client libraries. This makes it possible for applications to administer the server directly. This, in fact, is how TIBCO ActiveMatrix Service Bus manages the underlying EMS server that it uses.

EMS also provides a stand-alone EMS administration tool that provides a command-line administrative interface. Some versions of the TIBCO Administrator™ also provide plugins for EMS administration.

Finally, for those situations in which there are a significant number of EMS servers in use, there is the TIBCO Enterprise Message Service™ Central Administration server. This provides a centralized mechanism for conveniently managing multiple EMS server instances.

Message Delivery Transports

Conventional Message Delivery

In conventional JMS message delivery (Figure 8-2) each exchange between a receiving application and a JMS server involves an individual TCP protocol interaction. Thus the publication of a message to a topic with three subscribers will result in four messages on the network: the original message being sent and an additional message for each of the recipients. It will also require the JMS server to send three outbound messages.

Figure 8-2. Traditional JMS Topic Message Delivery

High-Fanout Message Delivery

Some solutions require the delivery of the same message to many recipients. The solution typically involves a JMS Topic with many subscribers. This is typically referred to as a high-fanout situation. When there are a large number of messages being delivered with high fanout, the volume of traffic may be limited by the available network bandwidth. In some cases, the capacity of the JMS server to deliver the messages may also limit the rate at which the messages can be delivered.

Multicast Message Delivery

To deal with high-fanout situations, EMS provides an alternative message delivery approach that utilizes multicast delivery over the network. Taking advantage of this approach requires a particular style of deployment shown in Figure 8-3. In this deployment pattern each recipient application has an EMS multicast daemon running on the same machine. Communication between the EMS server and the multicast daemon uses multicast and each message appears only once on the network. Communication between the daemon and applications on the same machine use TCP, but with local loopback. These communications do not appear on the network. There are also configuration requirements which are described in the EMS product manuals.

Figure 8-3. Architecture Pattern for Using Multicast Message Delivery

When multicast message delivery is properly configured and deployed, messages are delivered as shown in Figure 8-4. This delivery approach provides two efficiencies: One is that the EMS server only sends each message exactly once regardless of how many recipients there are. This reduces the amount of work the EMS server needs to do for each message. The other is that each message appears exactly once on the network regardless of how many recipients there are. This reduces the required network bandwidth.

Figure 8-4. Topic Message Delivery Using Multicast

There is one important limitation to consider when using this delivery pattern. In traditional JMS message delivery each client explicitly acknowledges the receipt of each message. Thus the JMS server knows whether or not the message was delivered successfully and, in the event of a failed delivery, will attempt to redeliver the message the next time a connection is established with the receiving application. With multicast delivery this acknowledgment is turned off. Consequently, a network issue can cause a loss of messages.

Another consideration with multicast is that the network itself must be multicast-enabled. Furthermore, if the receiving applications and the EMS server are on different subnets, multicast routing between these subnets must be configured. Thus it is administratively more complex to set up multicast routing as opposed to conventional message delivery.

Enterprise Message Service Feature Highlights

There are a number of EMS features of architectural interest. These are described in detail in the product manual, but we highlight them here for convenience. They include:

• Multiple message storage options, including both files and databases

• Support of JACI for authorization

• Support of JAAS for custom authentication and authorization

• Message compression

• Bi-directional connectivity with TIBCO Rendezvous^® and TIBCO SmartSockets^®