Взаимодействие с OSGi - Уровни взаимодействия с OSGi

Известный OSGi-евангелист Neil Bartlett начал интересную серию статей о разработке библиотек, способных корректно работать в среде OSGi.

В принципе, многие библиотеки могут работать в OSGi среде, даже если они не предоставляют OSGi-дескриптора (т.е. файла MANIFEST.MF, содержащего поля Bundle-SymbolicName и т.д.), если только они не используют паттерны, создающие проблемы, такие как сканирование ClassPath и вызовы Class.forName(). Данные библиотеки Neil обозначает термином compliant. Другие фреймворки могут более глубоко интегрироваться с OSGi, например использовать сервисы, настраиваться через Config Admin и т.д.

Чтобы сделать диалог между авторами библиотек и OSGi-сообществом более продуктивным Neil предлагает договориться о терминах и ввести следующую шкалу уровней взаимодействия между библиотекой и OSGi.

-1. Non-compliant - Использовать библиотеку в OSGi-среде сложно или совсем невозможно. В лучшем случае возможно использование библиотеки через дополнительный слой совместимости или с помощью внесения изменений в исходный/бинарный код. Например, библиотека использует вызовы Class.forName().

0. Neutral - Не OSGi-й JAR-файл можно использовать, если обернуть его в бандл (т.е. добавить необходимые заголовки в манифест) или поместив данный архив в Bundle-ClassPath.

1. Compliant - Библиотека распространяется в виде одно или нескольких OSGi-бандлов с корректно определенными манифестами. Все необходимые зависимости так же обеспечивают данный уровень взаимодействия и распространяются вместе с библиотекой или доступны из специального репозитория. Версии пакетов соответствуют семантической модели версионирования.

Для большинства библиотек нет необходимости обеспечивать уровень взаимодействия выше, чем первый, однако для сложных фреймворков, которые к тому же могут быть расширяемыми посредством плагинов, конфигураций, внедрения логгирования и другими способами, вводятся еще два уровня взаимодействия с OSGi:

2. OSGi-Assisted - Фреймворк "знает" об OSGi и использует его в ядре или модулях. Он является расширяемым с помощью сервисов, используя их в дополнение к другим механизмам и может обновлять (cope) данные сервисы динамически без необходимости перезапускать JVM.

3. OSGi-Powered - Фреймворк основан на OSGi и публикует сервисы, которые могут быть использованы в других частях нашей системы или вообще быть заменены нашей собственной реализацией. Такой фреймворк получает преимущества от использования стандартных сервисов OSGi: Log Service, Event Admin, Config Admin, HttpService. Однако, несмотря на все это, фреймворк может работать и вне OSGi-среды.

В последующих постах серии (первый из которых уже опубликован) Neil обещает поделиться информацией, необходимой для разработки библиотек/фреймворков, занимающих как можно более высокое место в приведенной выше пирамиде и в то же время не имеющих жесткой привязки к OSGi.

Я же в свою очередь постараюсь по возможности переводить мысли Neil'а на русский язык, а также делиться своими собственными идеями и примерами по этому поводу.

Оставайтесь на связи!

Ссылки:

• OSGi Bundle Quality or Bundle Information Repository


• OSGi Compliance Levels


• OSGi Readiness — Loading Classes

Понравилось сообщение - подпишитесь на блог или читайте меня в twitter