В мире информации необходимы как эффективные методы обмена ей, так и способы ее хранения. В каждой современной системе используется несколько различных СУБД, каждая из которых обладает своими достоинствами и была выбрана для удовлетворения определенных нужд. Однако, разнообразие в форматах порождает проблему совместимости и совместной работы с ресурсами. Чтобы решить проблему дублирования данных и несовместимости форматов, был начат проект Akonadi — четвертый из рассмотренных нами столпов KDE4.

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

В чем суть работы Akonadi и зачем он нужен?

Начнем с того, зачем всё это нужно. В KDE 3 приложения управления персональной информацией (такие, как Kontact) хранят свои данные и настройки раздельно, дублируя одинаковые данные. Связка KMail и KResources уже исчерапала все свои возможности, настала пора решить проблему разделяемых ресурсов и асинхронного доступа к ним: в KDE3 Kontact держит в оперативной памяти 6 копий вашей адресной книги! Кроме того, была цель создать нечто более стандартизированное — такому открытому проекту невозможно развиваться, не считаясь с нуждами и направлениями развития других крупных и важных проектов. Поэтому решено было создать клиент-серверную систему, основанную на стандартных форматах хранения и обмена данных, с поддержкой D-Bus, и не зависящую от платформы и инструментария разработки. Реализацией этой идеи и стал Akonadi.
Возникает резонный вопрос — не достаточно ли уже создано различных groupware решений, обещающих работать с любыми типами данных? Сразу же поясним: Akonadi — это не groupware сервер! Напротив, Akonadi является промежуточным хранилищем, уровнем абстракции для персональных данных. Он сродни рассмотренным ранее Phonon и Solid.


Данная диаграмма отображает основные аспекты архитектуры Akonadi. Все основывается на централизованном хранилище данных, доступ к которому осуществлен с помощью протокола, не привязанного к определенной платформе или языку программирования. Поверх этого протокола организован набор API, которые используются для доступа к персональной информации в хранилище. Есть два типа клиентов Akonadi. Первый тип — это приложения, такие как Kontact, Evolution, KOffice. Второй тип — это такие ресурсы, которые позволяют центральному хранилищу Akonadi обмениваться информацией с внешними источниками данных. Такими источниками могут быть groupware-сервера (например, GroupWise или OpenExchange), другие механизмы хранения данных (файлы формата iCalendar, vCard), или стандартные протоколы (IMAP, POP и т.д.).

Это далеко не полная диаграмма и она показывает упрощённый пример использования. Akonadi спроектирован как гибкая система, доступная широкому спектру приложений и ресурсов. Часть концепции Akonadi заключается в том, что добавление новых API, соответствующих клиентов и источников должно быть предельно простым.

Такая архитектура имеет несколько преимуществ перед тем, что было в KDE3:

1. Личные данные держатся в памяти в единственном экземпляре.
2. Система централизированна, поэтому любые изменения происходят единовременно, позволяя всем компонентам работать с самыми свежими версиями данных.
3. Архитектура Akonadi спроектирован для организации асинхронного обмена данными (больше не должно происходить «замирания» приложения при обмене данными).

Что Akonadi даст простым пользователям?

Для пользователя плюсы не так очевидны, но все же довольно существенны. Как уже было сказано выше, все приложения используют одно хранилище, поэтому нет необходимости в дублировании данных в памяти. Соответственно, меньшая ресурсоёмкость. Кроме того, для доступа к хранилищу используется расширенная версия протокола IMAP, что повышает скорость извлечения данных. Тот же протокол IMAP предоставляет базовые возможности поиска, которые могут быть реализованы и расширены в каждом отдельном приложении.
Всем наверняка знакомы такие апплеты Plasma как календарь, оставить заметку и т.п. — все они используют один общий ресурс Akonadi. И если раньше вы могли видеть проблемы синхронизации данных между приложениями (например, если Kopete меняла данные о контакте, а Konversation в это время просматривал их), то теперь вопросы синхронизации берет на себя сервер Akonadi и данные автоматически обновляются везде (например, дни рождения в плазмоиде календаря). Более того, синхронизация данных с удаленным сервером становится для пользователя совершенно прозрачной.

Кроме того, станет возможной более удобная интеграция личных данных в другие приложения KDE. Например, кроме имени пользователя можно будет отображать его фотографию в свойствах файла. Компоненты обмена данными между сервером Akonadi и источником данных (например, тот же groupware-сервер) разделены на отдельные процессы, что помогает избежать аварийного завершения работы всей системы в случае ошибки. Сбойный процесс компонента может быть просто перезапущен и данные будут загружены заново.

Что даст Akonadi программистам?

Поскольку Akonadi берёт на себя заботу о получении и хранении данных, что обычно является самой сложной частью в разработке PIM, то теперь разработка PIM-приложений стала проще. Например, каркас почтового клиента Mailody, использующего Akonadi, был написан за 10 минут.

Основные особенности архитектуры Akonadi:
* Общий кэш персональных данных

• Независимый от типов ресурсов дизайн
• Расширяемость
• Базовый доступ в режиме оффлайн, запись и воспроизведение изменений
• Базовая система обнаружения и разрешения конфликтов
• Ресурсы сгруппированы по профилям
• Элементы данных составлены их множества независимо получаемых частей

* Одновременный доступ позволяет вести фоновые процессы независимо от интерфейса

• Синхронизация почты, календаря и адресной книги с удаленными серверами
• Синхронизация с мобильными устройствами
• Позволяет инфраструктуре семантического окружения получать доступ к персональной информации
• Архивация
• Индексирование
• Поиск «вне-процесса»

* Многопроцессный дизайн

• Изоляция крэшэй
• Большие элементы не блокируют всю систему
• Линковка по IPC позволяет использование проприетарных компонент
• Установки тонкого клиента могут разделять компоненты для большей масштабируемости

Что значит независимый от типов ресурсов? Groupware, IMAP, MS Exchange, vCard и всё остальное — это отдельные ресурсы, поддержка которых осуществляется за счет разных движков. Аналогично Phonon и Solid, движки на разных платформах предоставляют теоретически неограниченные возможности по работе со всевозможными типами источников данных. Разработчикам же предоставляется единый API для работы, поэтому написание приложений для работы с персональной информацией становится на порядок легче.
Общий дизайн Akonadi и его составляющих описан в документации API. Более подробную информацию можно найти в странице проекта на Techbase.

Информация взята с официального сайта Akonadi, статьи об Akonadi в русской Википедии, а также из интервью Тобиаса Кёнига (Tobias Koenig), одного из ведущих разработчиков Akonadi, для kubuntu-de.org. Также были использованы слайды презентаций, выложенные на официальном сайте Akonadi.

Это кросс-пост моей статьи с WeLinux.ru