Technical deep dive: Integration messages and events

In an ever-changing technical landscape, businesses are continually trying to gain a competitive advantage and market share. Quite often, these larger companies have several systems, some legacy, that are critical to business operations. To unlock efficiencies and adapt to core business missions, there is a need to integrate with other platforms, applications, or disparate systems.

This blog explores why these concepts are essential in implementing a robust asynchronous integration, and the differences between the two.  

Outside of integration protocols and architectural patterns, messages and events are the basic building blocks of asynchronous communication.   

Asynchronous communication allows systems to have a high level of decoupling and operate within their own capabilities and boundaries.   

These provide fundamental aspects of data exchange and communication.  

Fundamentally, they both can provide communication between systems. They allow loosely coupled integration via data communication, allowing messages or events to flow without directly depending on consumers or providers.   

When done correctly, this allows integration to extend the application landscape and isolate system changes without impacting others.  

Through a conceptual lens, messages are there to make something happen, while events are what has happened.   

Messages originate with a specific purpose in mind, usually directed to one or more destinations with a common interface or contract. When a message is processed, it enables actions in the specific domain to be carried out. This, in turn, can trigger events that are broadcast across or beyond the domain. The main difference here is the provider of the events doesn’t know (or care) about the intended recipients.  

Messages are typically a single discrete unit of work intended to share data between parties. They constitute a full and rich data set relating to all available information. On the other hand, events are the consequences of system actions and are more related to real-time notifications. Events tend to be smaller and more focused on the real-world action that caused the change.  

For example…  

Messages can be characterised as a more generic form of communication, representing information communication between one or more parties, often via a proxy, such as a broker, queue or bus. Events rely on platforms which support event-driven architecture. Service-oriented architecture (SOA) defines Message Exchange Patterns (MEP), which form some common synchronous and asynchronous patterns such as request/response and event notification (Figure 2).

Message-based communication usually comes with the use of a message broker or service bus. This centralised infrastructure provides the ability to share common messages in a point-to-point (P2P) or publish-subscribe (pub-sub) model.   

This form of communication is common when messages only need to be consumed successfully and forgotten or if there is a need to manage a robust contract between parties.  

The P2P channel (Figure 3.1) can be one or more subscribers to the topic or queue. However, the message is only received and processed by one consumer. The pub-sub channel (Figure 3.2) allows multiple consumers to each get a copy of the message.  

The event-driven architecture supports the distribution of events across multiple parties with very loose coupling. The concept of event-sourcing is that a consumer can take events when they wish and treat them as a cumulative story of changes or notifications. Events are stored in an append-only log (Figure 4), which can be consumed as required. Just like reading a book, you can go back to a paragraph or a page and re-read the text, re-consume events, or jump to any point in the book as you so desire.  

 

This event-driven nature allows the consumer to support real-time consumption while managing the scalability and performance of their solution. The consumer also has the flexibility to process what they want, including replaying data.

The use of asynchronous integration allows components to be managed and changed in a loosely coupled, independent manner. However, there is often still semantic coupling in the structure and content of the messages or events.  

As previously discussed, cross-domain messages typically require a common structure so the integrating parties can form robust communication. This contract has shared ownership, and any changes could impact both parties. This ultimately means they are semantically tightly coupled.  

For events, the producer is the sole owner of the event semantics. The onus is on the consumer to transform the data to its needs. This means the coupling is only one way; the consumer is tied to the external data contract that the producer manages, reducing the overall coupling.  

The use of concurrent topics, contracts, and versioning can manage breaking changes. For example, if a producer makes a breaking change, they can now publish events using old and new versions. This allows the consumer to upgrade when they wish.  

Messages and events are core concepts in asynchronous integration but should be differentiated.   

Messages are usually used for data exchange and are often used in triggering action. They often imply a strong contract between the integrating parties and can be distributed through point-to-point or publish-subscribe channels.  

Events triggered from actions within domain components are well suited for real-time dynamic notifications, promoting responsiveness and flexibility. Events cater to event sourcing for better distributed communication.  

Messages and events foster reduced dependency and low coupling between components, providing a common mechanism to integrate more rigid and inflexible applications. This allows IT teams to integrate applications in a robust and responsive manner to support business goals and agility.  

For CIOs and CTOs, understanding the technical side of integration events and messages is critical to making informed decisions about future investments and strategy. This blog has walked through some complex aspects, but the key takeaway is how these details can directly impact your systems' efficiency, scalability, and long-term viability.

Incorporating the insights discussed here can help streamline decision-making processes, reduce risks of integration failures, and ensure that your team is aligned with the latest tech advancements.

Want to discuss how these insights apply to your current systems? Chat with one of our experts!