D-Bus (Desktop Bus) is a low-latency, low-overhead, easy-to-use message bus technology which supports application launch and linking. It is primarly used on GNU/Linux desktops but has been ported to other platforms including Microsoft Windows and Apple Mac OS X.  This post provides a quick overview of D-Bus concepts, some history, and some examples of how to use D-Bus in your shell scripts.
Originally both the KDE and GNOME desktop projects used CORBA for inter-application communication. Over time however, for various reasons, KDE migrated from CORBA to Desktop Comunications Protocol (DCOP) and GNOME migrated to Bonono. This lead to the situation where GNU/Linux desktop distributions had to support two different inter-application lauch and linking models and many standard desktop applications could not communicate seamlessly with each other. To ameliorate this unsatisfactory situation, D-Bus (the name was suggested by Harri Porten) was conceived and developed by Red Hat as part of the freedesktop.org project. The design of D-Bus was heavily influenced by DCOP. From the start, it was designed to be a replacement for the two competing technologies. The initial source code module was created by Havoc Pennington in late 2002. Development was quite slow with many changes to the wire protocol. However by 2006 the specification was relatively stable. First GNOME and then KDE made the decision to transition to D-Bus in order to support a single unified applcation linking and lauching technology on GNU/linux desktops.
In many ways D-Bus is similar to Sun Microsystems ToolTalk which is the undelying technology in Common Desktop Environment, and Microsoft’s Object Linking and Embedding (OLE) technology.
The basic D-Bus protocol is a low latancy peer-to-peer or client-server binary protocol. It is not intended for inter-machine use but rather for intra-machine use. It works in terms of messages rather than byte streams. A message bus is used when many-to-many communication is desired. Normally applications communicate via such a message bus but direct application-to-application communication is also possible.
When communicating on a message bus, applications can query which other applications and services are available, as well as activate one on demand. A daemon, or service, must be launched before any applications can connect to a message bus. This daemon is responsible for keeping track of the applications that are connected and for properly routing messages from source to destination. The D-Bus specification defines two well-known buses called the system bus and the session bus.