104

I was wondering if there is a clear distinction between message driven and event driven environments when we refer to SOA or middleware and generally in cases of application and enterprise integration. I understand that a user interface resembles an event driven model where our system intercepts action by the user.

Also it is clear that messaging supports systems based on publish/subscribe, sychronous or asynchronous communication, transactions etc.

But is there a difference in the middleware/soa/application intergration context? (architecture level). I am trying to consult sources such wikipedia (here, and here), but I am still somewhat confused. When should a developer prefer one solution over the other?

Are there examples or cases where one approach makes more sense than the other? Or any comprehensive resources and guides to implementing each one?

Many thanks for any insight.

denchr
  • 4,142
  • 13
  • 48
  • 51

12 Answers12

118

Here is a Typesafe/Reactive point of view on the question from Jonas Bonér. From the third paragraph of this blog post:

The difference being that messages are directed, events are not — a message has a clear addressable recipient while an event just happen for others (0-N) to observe it.

Joseph Woodward
  • 9,191
  • 5
  • 44
  • 63
john sullivan
  • 1,898
  • 2
  • 13
  • 21
  • 6
    It's also worth to emphasise the direct word, since we can broadcast a message between 0-N addressable recipients. – 4lex1v Oct 08 '15 at 06:31
  • But event is sent as a message at the end of the day. :/ – Mr_Hmp Oct 31 '20 at 13:00
  • so "process this payload" is a message (lets say generate an image based on some metadata, or extract data from some pdf) but, "i have processed this PDF or some change that has happened in system" is an event. obviously no-one can stop you from abusing this. – best wishes Apr 18 '21 at 10:43
58

This question was asked long time ago. I think a more modern and clear response is given by the Reactive Manifesto in Message-Driven (in contrast to Event-Driven):

A message is an item of data that is sent to a specific destination. An event is a signal emitted by a component upon reaching a given state. In a message-driven system addressable recipients await the arrival of messages and react to them, otherwise lying dormant. In an event-driven system notification listeners are attached to the sources of events such that they are invoked when the event is emitted. This means that an event-driven system focuses on addressable event sources while a message-driven system concentrates on addressable recipients. A message can contain an encoded event as its payload.

Digital Stoic
  • 1,229
  • 11
  • 20
41

Let's say you are building a Payment service for an eCommerce website. When an order is placed, the Order service will ask your Payment service to authorize the customer's credit card. Only when the credit card has been authorized will the Order service send the order to the warehouse for packing and shipping.

You need to agree with the team working on the Order service on how that request for credit card authorization is sent from their service to yours. There are two options.

  • Message-driven: When an order is placed, the Order service sends an authorization request to your Payment service. Your service processes the request and returns success/failure to the Order service. The initial request and the result could be sent synchronously or asynchronously.
  • Event-driven: When an order is placed, the Order service publishes a NewOrder event. Your Payment service subscribes to that type of event so it is triggered. Your service processes the request and either publishes an AuthorizationAccepted or an AuthorizationDeclined event. The Order service subscribes to those event types. All events are asynchronous.

An advantage of the event-driven approach is that other services could subscribe to the various events as well. For example, there might be a RevenueReporting service that subscribes to AuthorizationAccepted events and creates reports for the Finance team.

A disadvantage of the event-driven approach is that the system as a whole becomes a little harder to understand. For example, let's say the team working on the Order service asks you to replace the AuthorizationDeclined event with different events depending on why the credit card was declined (no funds, account closed, billing address incorrect, etc). If you stop publishing AuthorizationDeclined events, will that break some other service out there? If you have many events and services, this may be hard to track down.

Martin Omander
  • 3,223
  • 28
  • 23
  • 1
    This does not explain the effective difference between messages and events. Payment service can as well subscribe to newOrder messages. Are you trying to state the point that event driven is by default asynchronous ? Can you please clarify it further ? – Aarish Ramesh May 20 '20 at 17:29
  • In OO , it is interactive by message way between caller and callee... – fjjiaboming Jun 24 '20 at 06:52
  • 2
    I like this explanation. The bottom question would be when to use one or the other. My take on this would be to mind the "subscribers" and how to handle changes in the source and the effects on the subscribers. Using one approach or the other can make sense depending on your source and destinations a.k.a. subscribers. – FraK Nov 22 '20 at 09:34
  • 3
    @AarishRamesh - I think the main differences are: 1. Messages are point-to-point and the sender needs to know the receiver. 2. Events are one-to-many broadcasts and the sender does not need to know the receivers. – Martin Omander Dec 16 '20 at 20:06
36

Short answer to "is there a clear distinction" would be "no".

The terms are not quite interchangeable, but imply the same basic architecture - specifically that you will be triggering off of events or messages.

The first article you reference is about the low-level plumbing, the MOM or pub-sub "bus" that transports the messages on your behalf. The event-driven architecture is what you build on top of that framework.

The term event-driven, while also applying to GUI code, is not really at the same level of abstraction. In that case, it is a pattern in-the-small compared to building your entire enterprise along message/event driven lines.

sdg
  • 4,645
  • 3
  • 32
  • 26
  • 3
    I can't entirely agree with this answer, since there are clear distinctions between these two approaches, and they are listed in the other answers. – Pavel Jan 20 '20 at 07:04
  • 1
    @Pavel why do you think there are clear disdinctions? Other answers just put some difference between them, which are not absolute distinctions. – choxsword Aug 02 '21 at 05:32
11

Events driven architectures can be implemented with or without messaging. Messaging is one way to communicate events raised by producers to consumers in a reliable, guaranteed manner. Especially when producers and consumers are truly decoupled and may be hosted on different servers / VMs / environments and do not have direct access to any shared memory.

However in specific cases - when the consumer of the event is a function / callback registered within the same application itself, or when the consumer needs to be executed synchronously, then events-subscription can be implemented without messaging.

Sarat Buddhiraju
  • 166
  • 1
  • 3
5

The Message concept is abstract, more concrete types of message are Event and Command.

While messages have no special intent at all, events inform about something which has happened and is already completed (in the past). Commands trigger something which should happen (in the future).

Nitin Gaur
  • 922
  • 1
  • 14
  • 21
3

As it is put nicely in this article, in order to understand Event driven design, instead of looking at what it presents we have to observe what it conceals and that's nothing more than the very basic of programming; the "Call Stack".

In Event driven design the definition of method invocation goes right out of the window. There is no more caller and callee. That is a kiss goodbye to call sequence and order. System doesn't need to know in which order things have to happen. Hence, shared memory space, which is a prerequisite of Call Stack, becomes unnecessary.

In a Call Stack environment however, not only the caller has to know what happens next but it has to be able to associate a functionality to a method name.

Message oriented applications by default come with removal of shared memory. Publisher and subscriber don't need to share a memory space. On the other hand, all the other features (i.e. order, method name coupling and such) are not necessities.

If message passing is designed in order to comply with the axioms of event driven architecture, they could be considered identical. Otherwise there is a huge difference between them.

Jermin Bazazian
  • 1,932
  • 2
  • 17
  • 20
2

If we use event-driven approach, we usually want to send the source object in this event - component which published the event. So in subscriber we can get not only the data, but also to know who published this event. E.g. in mobile development we receive the View, which can be Button, Image or some custom View. And depending on the type of this View we can use different logic in subscriber. In this case we can even add some back-processing, modify source component - e.g. add animation to those source View.

When we use message-driven approach, we want to publish only the message with some data. It doesn't matter for subscriber who published this message, we just want to receive the data and process it someway.

Boris
  • 492
  • 4
  • 9
2

Event Driven Architecture and Message Driven Architecture are two different things and solves two different problems.

Event Driven Architecture focus is on how system is being triggered to function. Majority of the triggers that are thought as events in the context of EDA are the events generated by means other than keyboard and mouse. It is an EDA if that makes us think explicitly about event generator, event channel, event processing engine.

Keyboard and Mouse are obvious event generators however handling of these events is already taken care by various frameworks or runtimes and as an Architect we do not need to worry about it. There are other events which are specific to certain domain is what Architect is expected to think about. Example – Supply Chain Management events – pick, pack, despatch, distribution, retailer, sold etc. From Technical Perspective for Industrial IoT type of applications the events are – RFID Read, Bio-metric Read, Sensor Data, Barcode Scan, System Generated Events are the events that needs to be taken care explicitly because these events drive the functionality of the system.

Message Driven Architecture focus is to integrate the distributed systems by passing messages from one module to another modules of the system using standard Message Oriented Middleware.

DVK
  • 21
  • 1
1

In OO , it is interactive by message way between caller and callee... In GUI, we always say Event-Driven. We can see that if we need to manage the relationship both publisher and subscriber , we should use Event-Driven. If we manage upstream and downstream underlying more abstracted without strong dependencies (like upstream does not know the downstream), we should use Message-Driven. So in Message-Middleware context , it is no a clear distinction, and it is construction difference instead of design.

fjjiaboming
  • 191
  • 1
  • 3
  • 11
  • More details, the Event-Driven means there is one aggregate whose state changed, such as InventoryUpdated or UserCreated , or OrderPaid. – fjjiaboming Jun 24 '20 at 07:00
  • In one word, the message-driven is more abstracted than the event-driven. We care the processing state in Event-Driven than concrete data detail which the message-driven. – fjjiaboming Jun 24 '20 at 07:03
1

I have run into this thread while googling to tell differences between Message & Event. And after reading through all the responses above still haven't leaded me to the answer.

Then I have tried googling more and found the answer for me, so I'm gonna leave it here, hope that help someone likes me.

A Message is some data sent to a specific address. In Message Driven systems, each component has a unique address other components can send messages to. Each of these components, or recipients, awaits messages and reacts to them.

An Event is some data emitted from a component for anyone listening to consume.

Akka: Message Driven vs Event Driven

Viet Pham
  • 11
  • 1
  • 3
0

According to me:

  • in event driven architecture all the data transfer is done asynchronously, without worrying about the receiver/subscriber in mind. The data sent is a reaction of some action that happen. Generally the message size is small, but the message volume is a lot.
  • in message driven arch, the data is sent keeping in mind the receiver with a pre-defined message format, this transfer can be either synchronous or asynchronous. Although there is no rules to it, but the size of data is bigger as compared to event-driven archs and the data is sent in much lesser volume.
Mr_Hmp
  • 2,474
  • 2
  • 35
  • 53