Phil mossop
Senior integration consultant
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, which hold critical core importance to business operations. In order to unlock efficiencies and adapt to core business missions there is a need to integrate with other platforms, applications or disparate systems.
Why are messages and events so important to an integration strategy?
This blog explores why these concepts are essential in implementing a robust asynchronous integration, and what the differences are 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.
What are the similarities between messages and events, and why group these concepts together?
Fundamentally, they both can provide communication between systems. They allow loosely coupled integration via data communication, allowing messages or events to flow and not depend directly on consumers or providers.
When done correctly this allows integration to extend the application landscape and isolates system change without impacting others.
What are the differences between messages and events?
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, this enables actions in the specific domain to be carried out. This in turn can trigger events, which are broadcast across or beyond the domain. The main difference here is the provider of the events does not know or care about the intended recipients.
Messages are typically a single discrete unit of work with the intention of data sharing between parties. Messages 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).
What are the common use cases for message-based integration?
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.
What are the common use cases for event-based integration?
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 these 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, you can 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, while having the flexibility to process what you want including replaying data.
What are the implications of change with messages and events?
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 normally require a common structure so the integrating parties can form robust communication. This means there is a shared ownership of this contract, any changes to this contract 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, producer makes a breaking change, they can now publish events using old and new versions. This allows the consumer can upgrade when they wish.
Summary
Messages and events are core concepts in asynchronous integration, but they 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 a reduced dependency and low coupling between components which provides 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.
One reply on “Integration Strategies – Messages and Events”
Extremely well written article.