OpenBinder is a system for interprocess communication. It was developed at Be Inc. and then Palm, Inc.[2] and has more recently been used in the Android mobile phone platform developed by Google[3].
OpenBinder allows processes to present interfaces which may be called by other threads. Each process maintains a thread pool which may be used to service such requests. OpenBinder takes care of reference counting, recursion back into the original thread, and of course the inter-process communication itself. On the Linux version of OpenBinder the communication itself is achieved using ioctls on a given filehandle, communicating with a kernel driver.
In computing, D-Bus (Desktop Bus) is a simple inter-process communication (IPC) system for software applications to communicate with one another. Heavily influenced by KDE2–3's DCOP system, D-Bus has replaced DCOP in the KDE 4release. Most POSIX operating systems support D-Bus, and a port for Windows exists. It is used by Qt 4 and GNOME. In GNOME it has gradually replaced most parts of the earlier Bonobo mechanism.
Red Hat operates as the primary developer of D-Bus - as part of the freedesktop.org project. Freedesktop.org releases D-Bus under the terms of the GNU General Public License and of the Academic Free License as free software.
D-Bus allows programs to register with it in order to offer services. It also allows client programs to check for the availability of services. Programs can also register as waiting for events of the kernel, as in the case of hot-swapping hardware.
D-Bus functionality runs as a daemon: typically dbus-daemon. Users can run several instances of it, each called a channel.Most systems implement a privileged system channel, with a private instance for each logged-in user. The private instances are required because the system channel has access restrictions.
The system channel focuses on delivering the signals from the HAL (hardware abstraction layer) daemon to the processes interested in them. The mission of the private instances is to provide unrestricted communication among any applications of the user.
D-Bus has three architectural layers:[2]
a library, libdbus, that allows two applications to connect to each other and exchange messagesa message-bus daemon executable, built on libdbus, that multiple applications can connect to. The daemon can route messages from one application to zero or more applications, thereby implementing the publish/subscribeparadigm.wrapper libraries based on particular application frameworksThe design of D-Bus addresses two specific cases:
communication between desktop applications in the same desktop session; to allow integration of the desktop session as a whole, and address issues of process lifecyclecommunication between the desktop session and the operating system, where the operating system would typically include the kernel and any system daemons or processesEach application using D-Bus contains objects that usually map to GObject, QObject, C++ objects, or Python objects. Each D-bus object operates as an instance rather than as a type. Messages received over a D-Bus connection get routed to a specific object, not to the application as a whole. In this way, D-Bus resembles software componentry, as it appears to users as if they are interacting with an object across the IPC connection, whether or not there is an object on the other side.
To allow messages to specify their destination object, the system needs a way to refer to an object. Many programming languages refer to this as a pointer or reference. However, these references are implemented as memory addresses relative to the address space of the application, and thus can't be passed from one application to another.
To solve this, D-Bus introduces a name for each object. The name looks like a filesystem path, for example an object could have the name /org/kde/kspread/sheets/3/cells/4/5. D-Bus encourages human-readable paths, but developers are free to create an object named /com/mycompany/c5yo817y0c1y1c5b if it makes sense for their application.
The D-Bus objects' names are namespaced to keep different code modules separated. Namespaces are generally prefixed with the developer's domain name components (eg. /org/kde).
