I'm working on a simple piece of functionality (actually a ruby gem, but that is beside the point) which can be used to

  • receive and persist incoming messages
  • send and persist outgoing messages
  • supplies a hook to the implementing code for performing some action based on a received message. Could for example send a reply, but also perform other actions.

I'm struggling to find a short and concise name for this functionality. Does this bare resemblance to any named patterns, and if so which?

***** UPDATE *****

To be more specific, what I am actually doing here is receiving and sending SMS.

Starting to wonder if perhaps the most appropriate name for this functionality would be an SMS dispatcher. From the Dispatcher page on wikipedia (although it has nothing to do with computing):

Dispatchers are communications personnel responsible for receiving and transmitting pure and reliable messages

Or would using the dispatcher name for this concept cause confusion with other design patterns?

  • I'm not sure what you are doing, but this may have similarities with the Memento which is used for (de‑)serialization without breaking encapsulation. If your module creates specialized objects that perform this functionality for a specific class, then it is related to a factory. Any callback-based solution is of course related to the Strategy pattern. — I doubt these patterns actually fit. It would be helpful if you could contrast your design to these patterns.
    – amon
    Sep 18 '13 at 10:54
  • 1
    The Memento pattern is more about undoing changes to objecs, which is not something I'll be doing here. I guess you are right about the Strategy pattern, although the major concept here is that of receiving and sending messages. I've updated the question with some additional discussion.
    – rogerkk
    Sep 18 '13 at 16:42
  • Sounds like what you have is a messenger. (In the plain English sense of the word.) Sep 18 '13 at 17:23

There are many patterns associated with messaging, as there are lots of facets to this problem. There is an entire section in the book Enterprise Integration Patterns, which is summarized here: http://www.eaipatterns.com/toc.html

The pattern to use depends on some parameters, such as: is this a point-to-point message? is there one sender and many receivers? vice versa? many-to-many? how is the recipient determined?

Here's some general patterns:


A sender establishes a direct connection to one destination. i.e., a call to a web service, remote procedure call


A single source of messages are published to all subscribers. Think RSS or Twitter.


A dispatcher is used when there is a single source of messages and multiple destinations. All destinations receive each message and decide if they want to process it or not.


Uses context to determine the destination of a message. The decision can be based on content of the message or external state or rules. Typically uses many sources of messages and routes to one of many destinations.


A broker is similar to a router in that it consumes messages from multiple sources and determines the correct destination. It differs, however, in that it may have logic for translating a message and/or negotiating with the sender to send different content.

  • Thanks for a nice answer. In my case I guess a broker is the closest match, because: 1) I receive messages from a single SMS gateway, but the messages themselves can stem from many SMS users. 2) I will have some logic to handle incoming messages and decide what message to send and to whom, and 3) messages wil be sent back to a single SMS gateway, but again to different SMS users.
    – rogerkk
    Sep 19 '13 at 16:36

Not the answer you're looking for? Browse other questions tagged or ask your own question.