Библиотека сайта rus-linux.net
Фреймворк Jitsi
Глава 10 из книги "Архитектура приложений с открытым исходным кодом", том 1.
Оригинал: "Jitsi", глава 10 из 1 тома книги "The Architecture of Open Source Applications"
Автор: Emil Ivov
Дата публикации: 2012 г.
Перевод: Н.Ромоданов
Дата перевода: май 2013 г.
Creative Commons. Перевод был сделан в соответствие с лицензией Creative Commons. С русским вариантом лицензии можно ознакомиться здесь.
Jitsi это приложение, которое позволяет пользователям совершать видео и голосовые звонки, совместно пользоваться своими рабочими столами, а также обмениваться файлами и сообщениями. Что еще более важно, оно позволяет это делать поверх ряда различных протоколов - от стандартных XMPP (Extensible Messaging и Presence Protocol) и SIP (Session Initiation Protocol) и до проприетарных, например, Yahoo! и Windows Live Messenger (MSN). Оно работает в Microsoft Windows, Apple Mac OS X, Linux и FreeBSD. Оно написано большей частью на языке Java, но в нем также есть части, написанные в нативном коде. В этой главе мы взглянем на архитектуру OSGi приложения Jitsi, рассмотрим, как она реализована и как управляет протоколами, а также оглянемся на то, что мы узнали при ее создании [1].
10.1. Разработка Jitsi
Тремя наиболее важными ограничениями, которые мы должны были иметь в виду при разработке Jitsi (в то время имевшего название SIP Communicator), были поддержка многих протоколов, кросс-платформенные операции и удобство для разработчика.
С точки зрения разработчик поддержка многих протоколов сводится к наличию общего интерфейса для всех протоколов. Другими словами, когда пользователь отправляет сообщение, наш графический интерфейс пользователя должно всегда вызывать один тот же метод sendMessage независимо от того, будет ли текущий выбранный протокол фактически вызывать метод, который называется sendXmppMessage или sendSipMsg.
Тот факт, что большая часть нашего кода написана на языке Java, удовлетворяет, в значительной мере, нашему второму ограничению: кросс-платформенности операций. Тем не менее, есть вещи, которые в среде Java Runtime Environment (JRE) не поддерживаются или делаются не так, как нам это нужно, например, захват видео с веб-камеры. Поэтому нам требуется использовать DirectShow в Windows, QTKit в Mac OS X и Video for Linux [2] в Linux. Точно также, как и с протоколами, те части кода, которые управляют видео, не должны касаться деталей управления (они достаточно сложны для этого).
Наконец, удобство для разработчика означает, что разработчикам должно быть легко добавлять новые функции. Сегодня VoIP пользуются миллионы, причем тысячами различных способов; различные провайдеры и разработчики сервис-услуг придумывают различные варианты использования и предлагаю новые идеи, касающиеся новых возможностей. Мы должны быть уверены, что им будет легко использовать Jitsi так, как они хотят. Тот, кому нужно добавить что-то новое, должен прочитать и понять только те части проекта, которые требуется модифицировать или расширить. Кроме того, изменение, делаемое одним человеком, должно минимальным образом влиять на все остальные работающие части проекта.
Если подвести итог, то нам нужна была среда, в которой различные части кода были бы относительно независимы друг от друга. Должна была быть возможность в зависимости от операционной системы легко менять некоторые части, запускать другие, например, протоколы, параллельно тем, что уже действуют, и иметь возможность полностью переписать любую из частей, причем так, чтобы остальной код работал без каких-либо изменений. Наконец, мы хотели иметь возможность легко включать и выключать отдельные части, а также иметь возможность загружать в наш список плагины через Интернет.
Мы кратко записали требования к нашему собственному фреймворку, но вскоре отказались от этой идеи. Нам не терпелось как можно скорее начать писать код для VoIP и IM и нам казалось, что не интересно тратить пару месяцев на фреймворк для плагинов. Кто-то предложил технологию OSGi, и она, как оказалось, подходит идеально.
Продолжение статьи: 10.2. Jitsi и фреймворк OSGi.