message driven vs. event driven approaches to application integration

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.

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.

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

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.