Firstly, and it’s slightly picky, but probably relevant enough to mention: ‘D-Bus’ is a protocol which is typically used with a message bus daemon (typically dbus-daemon
, but other implementations have been written). It is possible to use the protocol without the daemon (for peer-to-peer messaging between processes on the same machine) or over a network, or whatever you want. The protocol just defines the type system, message structure, and call semantics.
I’ll assume for the rest of this answer that by ‘D-Bus’ you mean (as most people typically do) the combination of the protocol and dbus-daemon
.
Does D-Bus count as message-oriented middleware?
Sort of. Wikipedia says that MOM allows storing, routing or transforming of messages, and asynchronicity. D-Bus implements message queueing (but not if a peer is not connected to the bus; in that case an error is returned to the sender), limited routing of messages (broadcast or unicast) and no transformation of messages. Asynchronicity is provided by the D-Bus client libraries coupled with a poll loop.
Does D-Bus count as a message queue?
Sort of. As above, D-Bus implements ordered queueing of messages in the dbus-daemon
until the receiving peer reads them. It doesn’t store the queue on disk if the daemon is restarted or if the peer disconnects. The D-Bus specification defines the message ordering guarantees which D-Bus makes.
Is D-Bus like ZeroMQ?
I don’t know ZeroMQ very well, but it seems that the key difference is that D-Bus is for local IPC only, whereas ZeroMQ also targets IPC between multiple machines on a network. While it is possible to run D-Bus over TCP, this is not an officially supported configuration, and not what D-Bus is really designed for.