Three Message Exchange Patterns for Application Integration (With Examples)

When it comes to application integration, there are various ways to exchange data. One that stands out is using APIs (as long as they are provided) to extract or receive information, either in real time or in batches. Depending on the business needs, different message exchange patterns are applied. In this article, we list the most common ones, as well as illustrate them with concrete integration examples.

Synchronous vs. Asynchronous Communication

In general, message exchange patterns that enable data exchange between applications are either synchronous or asynchronous, though a combination of these two is also possible.

Synchronous

Synchronous communication is also called blocking communication because all operations in an application that send a request are blocked until it receives a reply. The connection between the sender and replier (in the API context, this would typically be the HTTP connection) stays open during this period of time. This type of communication is essential when the sender application needs an immediate response to continue with data processing.

Synchronous communication also means that all operations are performed one after the other, or in other words, in sequence. This is why using an integration middleware that ensures very high performance with low latency is key in such integration scenarios. After all, data needs to be processed at very high speeds so that no business operations get impeded.

Asynchronous

Another name for asynchronous communication is non-blocking communication because, as you may well have already assumed, the application that sends a request doesn’t have to wait for a reply in order to continue operating. The connection between the sender and replier will be closed as soon as the request has been sent out. This also means that multiple processes can occur in parallel.

This type of communication is especially effective when there are large volumes of data that need to be processed. It is a better fit when no immediate response is expected or required.

Asynchronous communication is considered to be more reliable than synchronous, as no application would have a timeout because of waiting for responses, which logically leads to higher services availability. Also, additional functionality can be implemented in the messaging system and not on the communication ends. But really, it completely depends on the use case. There are integration scenarios in which asynchronous communication simply won’t work no matter how good it is. This needs to be taken into consideration when deciding in favor of or against specific message exchange patterns.

Now, let’s have a look at those message exchange patterns, shall we?

Request – Response

This is a very typical message exchange pattern of synchronous communication, and it is what it says: an application sends a request to another application, or if an integration middleware is implemented, to the middleware. It then waits for a response or a timeout.

Example: in a real business situation, this would be the case when a support employee needs to call a customer from the interface of the corporate communication tool.

In this scenario, the communication tool doesn’t store customer’s account data but gets it from a CRM system that it is connected to. When the employee clicks on the Call button, the communication tool first sends a request for the telephone number to the CRM system and can perform the Call operation only after it receives this number back.

Asynchronous Request-Response

Although the Request-Response pattern is actually considered synchronous by nature, there is its asynchronous variation, which is called Request-Callback. In this case, the sender application doesn’t have to wait for a response to continue operating. Instead, it sets up a callback process to handle a reply.

Typically, this type of communication would require a specific ID assigned to an original request, as well as a callback address.

Example: the Request-Callback pattern is useful when more than one operation needs to be performed in sequence (for example, when an application not only loads data from other sources but also applies a complex process for its analysis, in which the output of one task is the input of the next one).

Fire and Forget

This message exchange pattern is also called one-way because an application sends a request and continues operating without waiting for a response from receiving application or system, although it will usually expect to get some acknowledgment of that (i.e., a response via webhook). It is a typical pattern of asynchronous communication.

Example: a very classic example is the regular synchronization of data between, say, a cloud-based CRM application and an on-premise ERP system so that data in both applications is up to date. Imagine a Sales employee adding some new account data or changing existing data in the CRM application.

CRM would spot the changes and push them, i.e., into a queue on an integration middleware, from where it will be at some point picked up by or pushed to the ERP system. It doesn’t really matter either for the user or for his or her business processes when the update occurs, as long as it occurs eventually.

Message Routing

Message Routing is an example of the Fire and Forget pattern when there are more than two applications that need to be integrated. 

Example: this might be the case when a company uses one system for billing customers, but two or more CRM systems for various groups of customers, divided by their locations (South America, North America, APAC, etc.) or industries (Automotive, Banking, Pharmaceuticals, etc.).

In this case, an integration middleware is basically a must. Naturally, certain routing rules, and if necessary, even splitting rules (in case only parts of one and the same document will be pushed to appropriate CRM systems) need to be defined properly. But without an integration layer between all applications involved, such integration scenario will be extremely difficult to address.

Publish and Subscribe

In a way, this message exchange pattern is similar to the Message Routing pattern, only it works the other way around. The receiver applications define what type of data they are interested in. When a sender application pushes data to a so-called broker (in other words, publishes it), the broker distributes this data in accordance with the receiver applications’ specifications.

It doesn’t mean, by the way, that there can be only one sender application; like it is with receiver applications, there can be any number of applications that send their data to the broker.

As you might have already guessed, the Publish and Subscribe pattern belongs to the group of asynchronous message exchange patterns.

Example: a good example of this pattern is an on-premise ERP suite of, say, an automotive manufacturer that collects data from all kinds of sources. This data is needed by multiple various applications, like a CRM, several analytics systems, a billing system, and so on. The advantages of this pattern are that, first, it is the most loosely coupled one (the applications involved don’t have to know anything at all about each other). Secondly, it presents an ideal way of distributing large amounts data between multiple applications and systems in a timely manner.