29

My question is coming from an somewhat uneducated perspective.

What are the relative merits of a "message passing" system vs an "event based" system.

Why would one choose one over the other? What are their strengths and weaknesses?

I would like to know not just "in theory", but also "in practice".

EDIT:

Specific problem:

I want to build system of plug-able components which behave as small scale services (each performing some small task and or providing some piece of information).

The services can:

  • be layered so that the output of one service can act as one of the inputs to another
  • have containment hierarchies so that one service can be contained by another without a specific input-output relationship as mentioned in the previous sentence

The goal of the system is to translate a single flow of low level events in another system into higher level information and functionality, and in addition provide a channel back to the other system providing a single series of events.

I can provide more detail if this isn't enough.

After looking around some more. This and this probably describes my situation better.

This looks like it may be a good fit for my situation: http://akka.io/

sylvanaar
  • 2,295
  • 1
  • 19
  • 26
  • 3
    You'll need to provide some context. Often event based systems are based via a message passing model, and the devils are in the details. In C# for example, a message passing model allows execution to exist on a different thread, where-as events are triggered on the calling thread. – Telastyn Apr 30 '12 at 13:31
  • 1
    I can ask the question based specifically on the details of my project, however I wanted to make it general enough for it to not just apply to me. – sylvanaar Apr 30 '12 at 13:33
  • 1
    As @Telastyn commented - "message passing" and "event based" are not mutually exclusive. – Oded Apr 30 '12 at 13:39
  • While there is a trend amongst semantics described as *event based* and those described as *message passing*, their behaviour will be specific to any given system. You only have to look at the number of options given in the [Overview](http://en.wikipedia.org/wiki/Message_passing#Overview) of message passing systems to see that there is little difference between simple *events* and some *messages*, but the semantics of other *messages* could be completely different. You need to tell us what problem you are [trying to solve](http://programmers.stackexchange.com/faq#dontask). – Mark Booth Apr 30 '12 at 14:29

6 Answers6

21

This is apples and oranges:

An Event Driven system can react to events passed as messages ( messages in this context are implied immutable non-shared data ) as the events are raised. This is a purely architectural design.

A Message Passing system can be driven by events that create and pass the messages. This is a purely implementation design.

The two are not mutually exclusive.

Example: You can implement an event driven design in any language which may also be a message passing environment as in Erlang.

17

In my experience the only specific difference is that in most message passing systems, the sender of the message is aware of (and often declares) who the recipient of the message is.

So instead of raising an event and anyone who is sucscribed to the event getting it, the sender defines some id of the intended recipient(s) or logical group of recipients and then either sends the message directly to them, or goes through a message broker (though the OS can be seen as a message broker in an event based system).

Obviously there's the case of threading that Telastyn mentions with C#'s implementation of events, but you can still create your own pub/sub model that executes on different threads.

Steven Evers
  • 28,200
  • 10
  • 75
  • 159
11

Much of the confusion between "message passing" and "event based" has to do with architectural vs. implementation details. I have seen (and written) event driven systems that actually use OS provided messages for their implementation. I am guessing you are really referring to architectural ideas.

As many people have already pointed out "message passing" and "event based" aren't really good enough terms to avoid ambiguity.

What are the relative merits of a "message passing" system vs an "event based" system.

Message Passing

I'm going to start out by guessing that when you say a "message passing" system, you are talking about a system which one object spends a message to a specific other object. When I think of a system based based on this paradigm, I more generally think of a system where an object that detects something knows who needs to be told about something. (I'm not specifying how it knows, just that it knows.)

This type of architecture is very good for systems where the producers and consumers are well known. Either the producer of a message knows who must receive it, or the consumer must know from who to get the message from.

If you are writing a banking application, one would expect you really want to know who you are sending your transactions to and who they are coming from.

Event Based

The other system I believe you are thinking about when you say an "event based" system is one where an object raises an "event" without knowing who (if anyone) will respond to it.

This type of event driven architecture is very good for systems where the producer does not care about who consumes the event or where the consumer doesn't really care about who produced the event.

In general, these systems are great where you do no know the relationship between consumers and producers, and where you expect the relationship to be dynamic.

One system I have used this in was a system where the application was actually composed of dynamically configured modules (plug-ins) that were loaded at run time. When a module was loaded, it would register for the events it cared about. The result was a system in which it was very easy to extend the functionality.

For instance, let's say condition A raised Event EA which normally caused response RA. The object that caused response RA simply registered to receive event EA and acted on it when it arrived. Now, let's say we want to add a new response to EA, called RA_1. To do this, we simply add a new object that looks for EA and generates response RA_1.

Here are a couple of examples (using your terminology):

  • "message passing": Your boss tells you to fill out your time sheet.
  • "event driven": The department secretary sends out an email to everyone reminding them that their time sheets are due today.
jwernerny
  • 988
  • 6
  • 12
3

In SOA you have the concept of Command Messages and Event Messages. There is a need for both.

However, command messages have a higher behavioural coupling to the recipient endpoint since it is explicitly asking the endpoint to perform some function. It need not be tied to a particular endpoint (this can be configured or determined at runtime).

Event messages, on the other hand, have no behavioural coupling between the sender/recipient since the sender has no idea what a recipient is going to do with the message. It doesn't even know if anyone is subscribed to the event.

For some more background you are welcome to peruse my service bus site here: http://www.servicebus.co.za

1

In my experience, the biggest difference between the two is that messages in a message-passing system are first-class objects, whereas events in event-driven systems are much simpler. Messages tend to carry information, and that information may be transformed, stored, retrieved and re-sent. Events tend to carry smaller, more focused bits of information that are immediately consumed and then discarded. They tend to be sent from an event source directly to one or more event sinks, whereas messages are more often routed among several receivers, and may be converted/translated/wrapped or otherwise processed at any point along the route. They use similar technologies (buses, queues, filters, etc) but they're really disparate beasts.

TMN
  • 11,313
  • 1
  • 21
  • 31
0

From a practical point of view, messages are typically implemented as a block of memory that is copied from the sender's address space to the receiver's address space (or is otherwise enforced to be an immutable object) so you do gain thread-safety immediately.

In some cases of message passing the sender must specify the receiver, but in some other cases you can just post a message to a mailbox, and anyone can listen for messages in that mailbox, so there is some flexibility in how tightly coupled they are. Of course, you can have a mailbox where the contract is "I will post a message to this mailbox when this event happens."

In the case of events you're registering a delegate or callback with the owner of the event. In object oriented programming this means the event owner keeps a reference to the object that registered to receive the event. This can sometimes lead to bookkeeping nightmares, trying to figure out what object forgot to unregister their event handler. It means the target can't be garbage collected until the event owner is garbage collected, even if the target is no longer doing anything useful.

Personally I would choose message passing over events, except in cases where events are forced on you, such as Windows GUI programming, etc.

Scott Whitlock
  • 21,874
  • 5
  • 60
  • 88
  • Just fyi, I solved the cycles problem (your book-keeping nightmare) in my C++ event system by storing weak_ptr and cleaning out any .expired() pointers from the set of listeners whenever the event was called. The event object *does not own* the recipient object and these pointer semantics make that clear. – Robinson Oct 23 '16 at 14:47