message driven vs. event driven approaches to application integration

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.

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.

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.