Java Message Service is an API that applications can utilize to create, send, receive, and read messages mostly asynchronously and reliably over a messaging system in order to build systems that are loosely coupled.

Enterprises are heavily dependent on messaging systems for their daily operations. It does not matter whether they are a large Fortune 500 company or small medium businesses. Here is a very high-level example of an architecture that the majority of investment banking IT businesses typically have in their global operations. Let's say that we are a fictional institution called Simple Bank PLC, a private limited company in the United Kingdom. Simple Bank relies on a division of labor, sometimes called silos, to separate the work of the trading desks from the work back office: the front office makes the deals on the trades and the back office validates records and manages the post-processing of the deal after the trades have been agreed.

In this simplified bank architecture, technically, Simple Bank has two systems: one for the front office and the other for the back office. How do these systems communicate over the entire life cycle of software enterprise applications that are installed in a bank and still have a long-term view of maintainability? The answer is that this simple bank installed a proprietary messaging system to act as a conduit between the two system and this systems allows asynchronous, reliable, and robust communication.

Here is the story: a long time ago, Simple Bank invested in enterprise Java in order to integrate their many bespoke systems with the JV and future-proof their architecture and strengthen their software development lifecycle. The bank started to use the JMS API as part of Java EE to write its own internal processes and applications around the message system.

Like similar investment banks, Simple Bank has several different components. In the front office, there is Exposure and Limits, which is an enterprise component to perform credit checking on trades. It has a Portfolio Management component that allows traders, sales, and marketing staff to manage accounts directly and indirectly for counterparties and private investment customers. After the year 2012, because Simple Bank now operates and trades also in the United States of America and it is listed as a legal entity on the stock market in New York, Simple Bank is required to comply with the Dodd-Frank (Reform and Consumer Protection Act: http://en.wikipedia.org/wiki/Dodd%E2%80%93Frank_Wall_Street_Reform_and_Consumer_Protection_Act). There is a huge signification investment in a recent Regulatory Reporting component that takes care of sending XML data to the US regulatory government bodies.

Moving to the back office, there is a component for an Electronic Management Information System, which is supposedly a very crucial component for the bank's board. The top senior executives require this component to find out about the bank's key market data, the business of running a bank, and the overall balance sheet: day-to-day, week-to-week, and month-to-month. There is a Profit and Loss center component in the back office system which typically is part of the proprietary electronic trading system (which is not illustrated) that Simple Bank relies on to create end-of-day reports. In the global operation of most investment banks, which are now 24-hour trading, the act of computing real-time profit and loss and trading days are complicated by time zones, local business holidays, and big data. And this brings up Batch Operations, which are key essential tasks such as calculating the entire trade volume at the end of the day and computing expensive derivative risk operations and trade rate curves that are essential long running operations.

All of these enterprise components need a way to communicate with each other. The old fashion way was to make Remote Procedure Calls, which is very low-level and imperative way of communication and requires knowledge about networking. The modern way is to allow each component to send messages to each other over a guaranteed delivery system. XML is the message content type of choice for a lot of investment banks. Today, many of them use a popular variant that falls under the guise of Financial Product Mark-up Language (FPML) to another. In our Simple Bank example, there are two of them: one dedicated system by IBM WebSphere MQ installed in the front office and the other is a Tibco Enterprise Messaging System middleware in the back office. There is an internal network; also an intranet that bridges the two message systems.

Why are there two different vendor systems? To add more salt to the wound, let's just say that Simple Bank was a result of a recent merger and acquisition situation. Simple Bank is a long term IBM customer and was taken over by Bigger and Better Bank, which is a long time Tibco customer. This sort of enterprise asset inconsistency is not untypical in a technology-driven business operation. Messaging systems are tied up with requirements, profitable business reasons, and real-world application of technology. They are an interesting mixture.

Messaging systems

There are two types of messaging, namely point-to-point (P2P) and publish-subscribe (Pub-Sub).

Point-to-point messaging

In point-to-point messaging, a producer sends a message over a queue channel and exactly one consumer receives it and processes it. A channel is a reliable conduit for a producer and consumer to communicate by messages. Once the message in the channel is delivered to the consumer, then it is no longer available in the channel.

In normal practice, production and consumption of messages takes place asynchronously. In other words, the producer does not have to block and wait whilst the message is being sent and the messaging system that delivers the message to the consumer is also not blocked on a Java thread. However, JMS 2.0 does allow you to synchronously publish messages. It is also possible within JMS 2.0 for a point-to-point consumer to receive messages both asynchronously and synchronously.

Tip

Point-to-point (P2P) model

Do not confuse this with another concept in distributed networking software that also shares the abbreviation (peer-to-peer) in message-oriented middleware. The P2P model is designed for messaging communication where there is one and only one component for each message.

The P2P model can be used in an e-commerce application that processes a customer order. A customer entry component sends an XML order to a warehouse system which will then process the order and update the business internal and external inventory. The warehouse system is responsible for reducing the stock count of products and therefore the e-commerce front end system at a later time shows a reduced stock frame.

Here is an illustration of a point-to-point model for a typical e-commerce application:

The message queues loosely couple the enterprise components to each other.

Publish-subscribe messaging

In publish-subscribe messaging, a producer sends a message over a topic channel and multiple consumers who have already subscribed to the same channel will receive the same message and therefore process it accordingly. If a consumer is not registered to the channel at the point when the channel is delivering the message, the consumer is not subscribed and will miss the message. Other consumers who are subscribed to the channel will receive the message.

You can think of the pub-sub model as a sort of TV broadcasting, although this similarity is allegoric. The viewer or digital tuner has to be tuned to the TV channel in order to receive the content.

The producer does not have to register with the topic channel in order to send a message, but they do need to know the topic name and how to find the topic channel. Consumers just have to subscribe to the topic channel and they can unsubscribe at any time. The topic channel is also a reliable conduit of messages. Each message supplied to the topic channel will be delivered to registered consumers. If there are no consumers on the topic channel, then the message will be lost at the point of delivery.

The pub-sub messaging model is inherently asynchronous in nature, since it delivers one message to probably hundreds or possibly thousands of consumers. In JMS, it is possible to block and wait on sending a message to a topic channel, but most of time applications do not do this. It is also possible for subscribers to receive messages both asynchronously and synchronously.

Tip

Pub-sub model

The pub-sub model makes use of topic channels, where the channel name is the destination address of the message. Multiple recipients can retrieve each message on the channel because the messaging system will handle the responsibility of delivering the message to consumers.

The biggest benefit of the pub-sub model is that the message producer (the publisher) does not need to be aware of the consumers (the subscribers) and therefore the model is amenable to the broadcasting of data. An application that sends financial stock, derivative prices, or market data benefits from the pub-sub model.

Following is an illustration of a pub-sub model for an investment bank. It shows only a very small subset of the physical topic channels for the front-office operations. There are a number of publishers on the left-hand side of the diagram which send XML message data to registered subscribers on the right-hand side.

The USD GBP and the EUR USD publishers are message producers in the Foreign Exchange (FOREX) domain. The USD GBP publisher updates on the movement of the US Dollar and British Pounds currencies and likewise the EUR USD publisher updates on USD Dollar and Euro movements.

External customers who use the bank's online e-commerce trading solution tend to trade only in response to the value of a single currency: "When the British Pound rises to £1.45 against the Dollar, perform this action." A consumer may be interested in Euros and not at all interested in Japanese Yen. Therefore, JMS message consumers are subscribed to a particular currency in order to receive real-time currency updates. (It is up to the applications to feed these updates to the external customer and these components, are not shown in the diagram.)

The Stock Loan and the Government Bond publishers are message producers in the Money Market (MM) domain. The message consumers registered for the Money Market topic will process updates to any external customers.

This pub-sub model is very appropriate for loosely-coupled producers and consumers that require a broadcast-style conduit of communication.