Библиотека сайта rus-linux.net
Фреймворк Telepathy
Глава 20 из книги "Архитектура приложений с открытым исходным кодом", том 1.
Оригинал: Telepathy
Автор: Danielle Madeley
Перевод: Н.Ромоданов
20.2. Как в Telepathy используется шина D-Bus
Взаимодействие компонентов Telepathy осуществляется через шину обмена сообщениями D-Bus, которая обычно является сессионной шиной пользователя. В D-Bus предоставляются возможности, обычные для систем межпроцессных взаимодействий: каждый сервис публикует объекты, имеющие строго определенные пути в пространстве имен, ведущие к этим объектам, например /org/freedesktop/Telepathy/AccountManager [3]. В каждом объекте реализовано несколько интерфейсов. Интерфейсы снова строго определены в пространстве имен, и имеют вид org.freedesktop.DBus.Properties и ofdT.Connection. В каждом интерфейсе предоставляются методы, сигналы и свойства, которые вы можете вызывать, слушать или опрашивать.
Рис.20.2: Концептуальное представление объектов, публикуемых сервисом D-Bus
Публикация объектов D-Bus
Публикация объектов D-Bus полностью выполняется библиотекой D-Bus, которая используется в данный момент. По сути, это отображение пути к объекту D-Bus в объект, используемый в программе и реализующий данные интерфейсы. Пути к объектам, публикуемые сервисом, предоставляются для доступа с помощью дополнительного интерфейса org.freedesktop.DBus.Introspectable.
Когда сервис получает входящий вызов метода, в котором указан путь назначения (например, /ofdT/AccountManager), на библиотеку D-Bus возлагается обязанность найти в программе объект, представляемый данным объектом D-Bus, а затем выполнить вызов соответствующего метода для этого объекта.
Интерфейсы, методы, сигналы и свойства, предоставляемые Telepathy, подробно описываются с помощью языка D-Bus IDL (Interface Definition Language, язык описания интерфейсов), в основе которого лежит язык XML, расширенный таким образом, чтобы можно было включать больше информации. Спецификации в таком виде можно анализировать автоматически и создавать документацию и привязки к различным языкам программирования.
Сервисы Telepathy публикуют различные объекты на шине. Центр управления публикует объекты для менеджера соединений и диспетчера каналов так, чтобы был доступ к их сервисам. Клиентские программы публикуют объект Client так, чтобы он был доступен для диспетчера каналов. Наконец, менеджеры соединений публикуют следующие объекты: объект сервиса, который может использоваться менеджером аккаунтов для запроса новых соединений, по одному объекту для каждого открытого соединения и по одному объекту для каждого открытого канала.
Хотя объекты D-Bus не имеют типов, а только интерфейсы, в Telepathy типы эмулируются несколькими способами. Путь к объекту, сообщающий нам, где находится объект, является соединением, каналом, клиентской программой, и т.д., хотя обычно вы уже знаете об этом, когда запрашиваете прокси доступ для этого объекта. Каждый объект реализует базовый интерфейс для его собственного типа, например ofdT.Connection или ofdT.Channel. Для каналов, это очень похоже на абстрактный базовый класс. Объекты каналов также имеют конкретный класс, определяемый типом данного канала. Снова это представлено с помощью интерфейса шины D-Bus. О типе канала можно узнать, прочитав свойство ChannelType в интерфейсе Channel.
Наконец, в каждом объекте реализуется ряд необязательных интерфейсов (как ни странно, тоже представляемые как интерфейсы шины D-Bus), которые зависят от возможностей протокола и менеджера соединений. Список имеющихся интерфейсов для данного объекта представлены в свойстве Interfaces базового класса объекта.
Для объектов соединений Connection типа \code{ofdT.Connection}, необязательные интерфейсы имеют имена вида - ofdT.Connection.Interface.Avatars (если в протоколе есть понятие аватаров), odfT.Connection.Interface.ContactList (если в протоколе предоставлен реестр контактов – это делается не везде) и odfT.Connection.Interface.Location (если в протоколе предоставлена геолокационная информация). Для объектов каналов Channel типа ofdT.Channel, конкретные классы имеют имена интерфейсов вида ofdT.Channel.Type.Text, odfT.Channel.Type.Call и odfT.Channel.Type.FileTransfer. Необязательный интерфейс точно также, как и объекты Connection, имеют имена вида odfT.Channel.Interface.Messages (если канал может передавать и получать текстовые сообщения) и odfT.Channel.Interface.Group (если данный канал подключен к группе, содержащей много контактов, например, к многопользовательскому чату). Так, например, в текстовом канале реализуются, как минимум, интерфейсы ofdT.Channel, ofdT.Channel.Type.Text и Channel.Interface.Messages. Если это многопользовательский чат, в нем также будет реализован интерфейс odfT.Channel.Interface.Group.
Почему свойство Interfaces, а не анализ в самой шине D-Bus?
Вы можете поинтересоваться, почему в каждом базовом классе реализовано свойство Interfaces, вместо того, чтобы воспользоваться средствами анализа, имеющимися в самой шине D-Bus, которые бы нам сообщали, какие имеются интерфейсы. Дело в том, что в различных объектах каналов и соединений могут, в зависимости от возможностей канала или соединения, предлагаться различные интерфейсы, которые отличаются друг от друга, но в большинстве реализаций средств анализа D-Bus предполагается, что все объекты одного и того же класса объектов будут иметь одинаковые интерфейсы. Например, в telepathy-glib интерфейсы D-Bus, перечисляемые с помощью средств анализа D-Bus, берутся их реализаций классов интерфейсов объекта, которые определяются статически на этапе компиляции. Мы справляемся со всем этим благодаря наличию средств анализа в шине D-Bus, предоставляющих данные обо всех интерфейсах, которые могли бы быть в объекте, и благодаря использованию свойства Interfaces, указывающего, какие интерфейсы действуют на самом деле.
Хотя в самой шине D-Bus нет проверки того, что в объектах соединений присутствуют интерфейсы, относящиеся только к подключениям, и т. д. (поскольку в шине D-Bus не используется концепция типов, а лишь концепция интерфейсов, именуемых произвольным образом), мы для того, чтобы реализовывать такую проверку внутри языковых привязок фреймворка Telepathy, можем пользоваться информацией, имеющейся в спецификациях Telepathy.
Почему и как был расширен язык спецификаций IDL
В существующем языке спецификаций IDL шины D-Bus определяются имена, аргументы, ограничения доступа и сигнатуры методов, свойств и сигналов для типов D-Bus. Но в нем не поддерживается документирование, механизмы привязок и именованные типы.
Чтобы обойти эти ограничения, в XML было добавлено новое пространство имен XML, предоставляющее требуемую информацию. Это пространство имен для того, чтобы его можно было использовать другими интерфейсами API шины D-Bus, было разработано в наиболее обобщенном виде. Были добавлены новые элементы, среди которых есть возможность прямо внутрь интерфеса API добавлять документацию, описание обоснования тех или иных решений, вводную часть, отмечать устаревшие версии и возможные исключения, возникающие в методах.
Сигнатуры типов D-Bus являются низкоуровневым описанием, определяющим какие данные должны быть сериализированы использования в шине. Сигнатура типов D-Bus могут выглядеть, например, как (ii) (что представляет собой структуру, содержащую два элемента int32), или может быть более сложной. Например, a{sa(usuu)} - это ассоциативный массив, который ассоциирует строку с массивом структур, содержащих элементы uint32, string, uint32, uint32 (смотрите рис.20.3). Эти типы, хотя и описывают формат данных, не придают никакого семантического смысла информации, хранящейся в объектах этих типов.
Чтобы предоставить программистам семантическую прозрачность и усилить типизацию привязок к языкам программирования, были добавлены новые элементы, позволяющие именовать простые типы, структуры, ассоциативные массивы, перечислимые типы (enums) а также флаги, предоставлявшие их сигнатуры, а также документацию. Также были добавлены элементы, эмулирующие наследование объектов шины D-Bus.
Рис.20.3: Тип (ii) и тип a{sa(usuu)} шины D-Bus
Продолжение статьи: Хэндлы ( Handles).