When it comes to application integration, there are various ways to exchange data between them. One that stands out is using their 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, and in this article, we would like to 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 sends a request are blocked until it receives a reply. The connection between the sender and replier (in the API context, this would be typically 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 message exchange patterns also mean 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 speed so that no business operations get impeded.
Asynchronous
Another name for asynchronous communication is non-blocking communication, because, as you might 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 needs to be processed, and is a better fit when no immediate response is expected or required.
Asynchronous message exchange patterns are 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 when asynchronous communication simply won’t work, however fine it is. This needs to be taken into consideration when deciding in favour or against specific message exchange patterns.
[clickToTweet tweet=”#Enterprise Application #Integration: Making the right choice of message exchange patterns. #EAI #API” quote=”Enterprise Application Integration: Making the right choice of 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 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 need 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 acknowledgement of that (e.g. a response via webhook). It is a typical pattern of asynchronous communication.
Example: A very classic example would be 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. Imaging a Sales employee adding some new account data or changing existing data in the CRM application.
CRM would spot the changes and push them, e.g. 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/her business processes when the update occurs – immediately or in an hour -, 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 e.g. their locations (South America, North America, APAC) 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 an integration scenario will be extremely difficult to address.
[clickToTweet tweet=”Choosing right #integration #middleware is key to mastering various integration scenarios. #EAI #API ” quote=”Choosing right integration middleware is key to mastering various integration scenarios.”]Publish and Subscribe
In a way, this message exchange pattern is similar to the Message Routing pattern, only it works the other way round. 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 would be 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 advantage of this pattern is that first, it is the most loosely coupled one, – the applications involved doesn’t have to know anything at all about each other. And secondly, it presents an ideal way of distributing large amounts of data between multiple applications and systems in a timely manner.
