message driven vs. event driven approaches to application integration

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.

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.

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.

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.

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.

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.

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).

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.

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.

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.

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.

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

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.