Составители:
Рубрика:
146
Именуются они привычным для ОО-программистов образом, например рассматриваемый D-BUS
экспортирует интерфейс “org.freedesktop.DBus”.
Каждое сообщение D-BUS, передаваемое по шине, имеет своего отправителя и своего получателя,
их адреса называются путями объектов, поскольку D-BUS предполагает, что каждое приложение
состоит из набора объектов, а сообщения пересылаются не между приложениями, а между объектами
этих самых приложений.
Однако, объектов и интерфейсов недостаточно для реализации некоторых интересных
возможностей, и D-BUS также предусматривает концепцию сервисов. Сервис — уникальное
местоположение приложения на шине и пространство имён. При запуске приложение регистрирует
один или несколько сервисов, которыми оно будет владеть до тех пор, пока самостоятельно не
освободит, до этого момента никакое другое приложение, претендующее на тот же сервис, занять его
не сможет. Именуются сервисы аналогично интерфейсам, а сам D-BUS экспортирует, соответственно,
сервис “org.freedesktop.DBus”.
Сервисы делают доступной еще одну функцию — запуск необходимых приложений в случае
поступления сообщений для них. Для этого должна быть включена автоактивация, и в конфигурации
D-BUS за этим сервисом должно быть закреплено одно приложение. Тогда D-BUS сможет его
запустить при появлении сообщения.
После закрытия приложения ассоциированные сервисы также разрегистрируются, а D-BUS
посылает сигнал о том, что сервис закрыт. Другие приложения могут получать такие сигналы и
соответствующим образом реагировать.
Сообщения в D-BUS бывают четырех видов:
· вызовы методов,
· результаты вызовов методов,
· сигналы,
· ошибки.
Первые предназначены для выполнения методов над объектами, подключенными к D-BUS;
посылая такое сообщение, вы выдаете задание объекту, а он после обработки обязан возвратить вам
либо результат вызова, либо ошибку через сообщения соответствующих типов. Сигнальные же
сообщения, как им и полагается, ничуть не заботятся о том, что и как делается объектами, они вольны
воспринимать их как угодно (равно как и не получать их вовсе).
Чтобы сообщение достигло определённого объекта, необходим способ сослаться на объект. Во
многих языках программирования это реализуется с помощью указателя. Однако, эти указатели
реализуются как адреса памяти, относящиеся к локальному адресному пространству приложения, и не
могут быть переданы от одного приложения другому.
Поэтому в D-Bus у каждого объекта своё, уникальное имя, которое выглядит как путь в файловой
системе. Например, объект может быть именован как “org/kde/kspread/sheets/3/cells/4/5”.
Предпочтительны имена, которые несут какую-либо смысловую нагрузку, тем не менее, разработчики
могут выбрать и имя /com/mycompany/c5yo817y0c1y1c5b, если это имеет смысл для их приложения.
Имена объектов находятся в пространствах имён, чтобы обеспечить разграничение разных
программных модулей. Пространствам имён обычно даётся префикс, специфичный для разработчика,
например “/org/kde”.
Кроме того, после подключения к шине приложение может настроить какие сообщения оно
желает получать, путем добавления «масок». Маски представляют собой наборы правил для
сообщений, которые будут доставляться приложению, фильтрация может основываться на
интерфейсах, путях объектов и методах. Таким образом, приложения будут получать только то, что
им необходимо, проблемы доставки в этом случае берет на себя D-BUS.
Реализация рассмотренного выше примера (опуская детали) будет следующей:
Приложение А:
//Создаётся интерфейс DBus
QDBusInterface remoteApp("com.example.ImageSaver","/ImageSaver/Operations",
"org.example.RPN.ImageSaver");
//Передаём SMS в сервис
Страницы
- « первая
- ‹ предыдущая
- …
- 144
- 145
- 146
- 147
- 148
- …
- следующая ›
- последняя »
