Design patterns for messaging / event driven infrastructure

Question

Hi,

I'm building my first system that relies heavily on a message queue for reasons other than scaling. To cut a long story short there will be many clients connected to a central server via the internet, each client has the ability to edit data on the server, when such an event occurs the other clients need to be updated live.

Does anyone know of any established design patterns covering such scenarios?

The obvious work flow is this:

User edits UI -> record is edited on the db -> message is added to the queue -> other clients update

My only problem with this workflow is that the UI that edited the record will also be listening for the message and likely without some hackery also then unnecessarily update itself. Nothing wrong with this in principle, but my experience with GUI patterns (which I imagine will be similar to messaging patterns) such as Martin Fowlers Passive View give me a feeling that this type of approach may not be the best way to go.

Cheers,

Chris

Answer 1

The Observer Pattern would seem to fit your problem best. Sometimes the GoF book is still good to look at. :)

http://en.wikipedia.org/wiki/Observer_pattern

Answer 2

One solution (which would benefit you in other ways, e.g. logging/auditing) is to include the client's ID (PID+hostname?) into the record, then clients listening to broadcast messages can easily filter out the messages whose "updated by client" field matches their own ID.

This may or may not be a pattern (if it is, I'd appreciate someone adding a comment/edit with the name), but it does solve your problem.