Asynchronous + Message Bus

Think Asynchronous, not Synchronous; Message Bus, not Point To Point.

It's a moment of epiphany when I realized the two related concepts are the key to many, many nagging software engineering problems of mine. Neither of them are alien to me, and I'm aware of them for quite a while. It's just that I've never realized how universal the patterns are, and how it applied to so many things. asdfe

Consider: how would you elegantly show the progress of a large file copy across several different user interfaces? (e.g. text, GUI, web?) It's tempting to get lost in low level details like Dependency Injection, when it's better to decouple the file copy process and the progress display into two asynchronous thread or process, and then send out periodic progress events to a Message Bus where interested user interfaces can display them. Caveat: this only applies to slow operations. This even allows for more than one user interface (listener) per operation. Traditionally, the file copy operation would be the same process that updates the User Interface's progress bar synchronously.

That was just the beginning as I found more and more problems can be elegantly solved by thinking asynchronously. AJAX web interfaces. dbus's interface between network events and the NetworkManager applet. Qt's Signals and Slots. Pipelining. Everyone of them are related.

Phrasing their definition to relate to each other:

Asynchronous: issue a request, but don't expect an immediate response. You'll get notified when the response is completed.

Message Bus: don't choose what component to talk to directly, instead send and forget to the bus (aka Message Queue, Channel, Slot), and other interested components themselves to choose to listen to the bus.