Наши партнеры

UnixForum

Библиотека сайта rus-linux.net

Фреймворк Telepathy

Глава 20 из книги "Архитектура приложений с открытым исходным кодом", том 1.

Оригинал: Telepathy
Автор: Danielle Madeley
Перевод: Н.Ромоданов

20.5. Устойчивость к ошибкам

Одним из ключевых преимуществ фреймворка Telepathy является его устойчивость к ошибкам (robustness). Компоненты являются модулями, поэтому проблемы в одном компоненте не должны выводить из строя всю систему. Ниже перечисляются некоторые из особенностей фреймворка Telepathy, которые делают его устойчивым к ошибкам:

  • Менеджер аккаунтов и диспетчер каналов могут восстанавливать свое состояние. Когда запускается центр управления (единственный процесс, в состав которого входит менеджер аккаунтов и диспетчер каналов), он просматривает имена сервисов, зарегистрированных в текущий момент на сессионной шине пользователя. Все соединения, которые он найдет и сможет проассоциировать с известным аккаунтом, будут привязаны к этому аккаунту (вместо того, чтобы устанавливать новое соединение), а и из работающих клиентских программ будет получен список каналов, которые они обрабатывают.
  • Если клиентская программа пропадает, а канал, который она обрабатывает, остается открытым, то диспетчер каналов перезапустит ее клиентскую программу и передаст ей канал.
  • Если клиентская программа повторно выходит из строя, диспетчер каналов может попытаться запустить другую клиентскую программу, если таковая имеется, или закрыть канал (чтобы предотвратить повторный выход клиентской программы из строя на тех данных, которые она не способна обработать).

    Текстовые сообщения, прежде чем они исчезнут из списка ожидающих сообщений, требуют подтверждения. Подразумевается, что клиентская программа подтвердит получение сообщения как только она будет уверена, что пользователь увидел это сообщение (то есть оно было показано в активном окне). Таким образом, если клиентская программа выйдет из строя, пытаясь выдать сообщение, сообщение останется в канале в очереди ожидающих сообщений как ранее не показанное.

  • Если из строя выйдет соединение, менеджер аккаунтов перезапустит его. Очевидно, что содержимое любых каналов, у которых есть состояние (stateful), будет потеряно, но это повлияет только на соединения, запущенные в данном процессе, и не повлияет на другие. Клиентские программы могут следить за состоянием соединений и просто повторно перезапрашивать информацию, например, реестр контактов, а также не повлияет на те каналы, у которых нет состояния (stateless).

20.6. Расширение Telepathy: механизм sidecars

Не смотря на то, что спецификация Telepathy старается охватить широкий спектр возможностей, предоставляемых коммуникационными протоколами, некоторые протоколы сами являются расширяемыми [4]. Разработчикам фреймворка Telepathy хотели сделать так, чтобы можно было использовать такие расширения без необходимости расширения самой спецификации Telepathy. Это было сделано с помощью механизма sidecars.

Механизм sidecars обычно реализуется с помощью плагинов менеджера соединений. Клиентская программа вызывает метод, запрашивающий sidecar, в котором реализован данный интерфейс шины D-Bus. Например, в чьей-то реализации списков приватности XEP-0016 может быть реализован интерфейс с названием com.example.PrivacyLists. Затем метод вернет объект D-Bus, предоставленный плагином, который должен реализовывать этот интерфейс (и, возможно, другие интерфейсы). Объект существует вместе с основным объектом соединения (наподобие мотоциклетной коляски - «sidecar», которая крепится сбоку мотоцикла).

История механизма sidecars

В самом начале разработки фреймворка Telepathy, в проекте One Laptop Per Child («Каждому ребенку свой ноутбук») для совместного обмена информацией между устройствами потребовалась поддержка своих собственных расширений протокола XMPP (XEPs). Они были добавлены прямо в Telepathy-Gabble (менеджер соединений для XMPP) и предоставлялись через недокументированные интерфейсы объекта соединения. В конце концов, всё больше и больше разработчиков хотело поддерживать конкретные расширения XEP, для которых не было аналогов в других коммуникационных протоколах. Было решено, что для плагинов необходим новый, более общий интерфейс.

20.7. Беглый взгляд внутрь менеджера соединений

Большинство менеджеров соединений написаны с использованием языковых привязок к C/GLib, причем был разработан ряд высокоуровневых базовых классов, которые делают более простым написание менеджеров соединений. Как упоминалось ранее, объекты D-Bus публикуются из объектов программы, в которых реализован ряд интерфейсов, отображаемых в интерфейсы D-Bus. В библиотеке Telepathy-GLib представлены базовые объекты для реализации объектов менеджеров соединений, соединений и каналов. В этой библиотеке предлагается интерфейс реализации менеджера каналов. Менеджеры каналов являются фабриками, которые можно использоваться для того, чтобы с помощью BaseConnection получать экземпляры объектов каналов и управлять ими при публикации их на шине.

В привязках также предоставляется то, что называется миксинами (mixins). Их можно добавлять к классу с тем, чтобы с помощью одного и того же механизма предоставлять дополнительные функциональные возможности, абстрагировать спецификации API, а также обеспечивать обратную совместимость между новыми и устаревшими версиями API. Самым распространенным примером использования является миксин, который добавляет к объекту интерфейс свойств D-Bus. Также есть миксины для реализации интерфейсов ofdT.Connection.Interface.Contacts и ofdT.Channel.Interface.Group и миксины, позволяющие с помощью одного и того же набора методов реализовывать старые и новые интерфейсы присутствия и старые и новые интерфейсы поддержки текстовых сообщений.

Рис.20.5: Пример архитектуры менеджера соединений

Использование миксинов для решения проблем с ошибкой в API

Одним из мест, где миксины были использованы для исправления ошибки в спецификации Telepathy, является TpPresenceMixin. Исходный интерфейс, предложенный в Telepathy (odfT.Connection.Interface.Presence), был сильно переусложнен, его было тяжело использовать при реализации соединений и клиентских программ, и в нем была представлена та функциональность, которая отсутствовала в большинстве коммуникационных протоколах, а в остальных - использовалась редко. Этот интерфейс был заменен более простым интерфейсом (odfT.Connection.Interface.SimplePresence), в котором была представлена функциональность, необходимая пользователям, и которая которая действительно была реализована в менеджерах соединений.

В миксине присутствия реализованы оба интерфейса соединения, позволяющие старым клиентским приложениям продолжать работать, но на функциональном уровне более простого интерфейса.

Продолжение статьи: Усвоенные уроки.