D-Bus (сокр. Desktop Bus) — система межпроцессного взаимодействия, которая позволяет приложениям в операционной системе сообщаться друг с другом.
D-Bus является частью проекта freedesktop.org. Она обладает высокой скоростью работы, не зависит от рабочей среды, работает на POSIX-совместимых операционных системах, также существует версия для Windows (пока на стадии разработки).
Состоит из двух частей: демона и низкоуровневого API. Существуют высокоуровневые библиотеки для фреймворков Qt, Java, GLib, C#, Python, Ruby и библиотека для C++.
Приложения одной среды рабочего стола должны тесно взаимодействовать между собой. В графической среде KDE для этого не так давно использовался DCOP, но другие настольные среды (например, GNOME) не имели аналогичных систем.
Существовала возможность сообщения посредством CORBA, SOAP или XML-RPC, но CORBA больше подходит для систем уровня предприятия, чем для настольных графических сред (KDE и GNOME за время своего существования прошли этап использования CORBA, тогда как SOAP и XML-RPC предназначены для веб-служб).
Раньше GNOME использовал Bonobo, основанный на CORBA, но из-за зависимости от GObject, Bonobo не использовался в других рабочих средах, а низкое быстродействие CORBA сказывалось на скорости всей среды.
Требовалось организовать обмен сообщениями между приложениями двух разных сред. Для решения этой задачи и был создан проект D-Bus. Реализация оказалась удачной и впоследствии было решено перевести проект KDE 4 на использование D-bus.
D-Bus предоставляет системе несколько шин:
- Системная шина
- Создаётся при старте демона D-Bus. С её помощью происходит общение различных демонов, таких как UPower, а также взаимодействие пользовательских приложений с этими демонами.
- Сессионная шина
- Создаётся исключительно для пользователя, авторизовавшегося в системе. Для каждой такой шины запускается отдельная копия демона, посредством неё будут общаться приложения, с которыми работает пользователь.
Каждое сообщение D-Bus, передаваемое по шине, имеет своего отправителя. В случае, если только сообщение не есть широковещательный сигнал, то оно имеет и получателя. Адреса отправителей и получателей называются путями объектов, так как D-Bus предполагает, что каждый процесс в системе состоит из набора объектов, а сообщения пересылаются не между приложениями, а между объектами этих самых приложений.
Каждый объект может поддерживать один или более интерфейсов, представляемых в виде именованных групп методов и сигналов — аналогично интерфейсам Glib, Qt или Java.
D-Bus также предусматривает концепцию сервисов. Сервис — уникальное местоположение программного процесса на шине. При запуске программа регистрирует один или несколько сервисов, которыми она будет владеть до тех пор, пока самостоятельно не освободит, до этого момента никакая иная программа, претендующая на тот же сервис, занять его не сможет. Именуются сервисы аналогично интерфейсам. После закрытия (завершения) программы ассоциированные сервисы также убираются из регистра D-Bus, D-Bus же посылает сигнал о том, что сервис закрыт.
Сервисы D-Bus делают доступной ещё одну функцию — запуск необходимых программ в случае поступления сообщений для них. Для этого должна быть включена автоматическая активация, а в конфигурации D-Bus за этим сервисом должна быть закреплена одна программа.
После подключения к шине программа должна указать, какие сообщения она желает получать, — путём добавления масок совпадений (matchers). Маски совпадений представляют собой наборы правил для сообщений, которые будут доставляться программе. Фильтрация может основываться на интерфейсах, путях объектов и методах.
Сообщения в D-Bus бывают 4 видов:
- Вызовы методов.
- Результаты вызовов методов.
- Сигналы (широковещательные сообщения).
- Ошибки.
В D-Bus у каждого объекта своё уникальное имя, которое выглядит как путь в файловой системе. Например, объект может быть именован как «/org/kde/kspread/sheets/3/cells/4/5». Предпочтительны имена, которые несут какую-либо смысловую нагрузку, тем не менее, разработчики могут выбирать и имена вроде «/com/mycompany/c5yo817y0c1y1c5b», если это имеет смысл для их программы.
Имена объектов находятся в пространствах имён, чтобы обеспечить разграничение разных программных модулей. Пространствам имён обычно даётся префикс, специфичный для разработчика, например /org/kde.