Каково различие между пакетами OSGI и компонентами?

Компонент :

• активный участник системы
• , осведомленный о своей среде и адаптирующийся к ней {{1 }}
  • среда = службы, предоставляемые другими компонентами
  • среда = ресурсы, устройства, ...
• может предоставлять службы другим компонентам и использовать службы из других компонентов
• имеют жизненный цикл

Вкратце:

• Компонент предоставляет услуги
• Пакетное управление жизненным циклом

Пакет может иметь только один активатор (требуется BundleContext ) и может иметь столько активных компонентов, сколько вы хотеть.
Это означает, что вы можете попытаться объединить в одном активаторе несколько слабо связанных задач в один класс.
Вот почему может быть проще управлять этими компонентами с помощью декларативных служб через SCR ("среда выполнения компонентов службы", которая является "расширителем"). пакет », реализующий новую и улучшенную спецификацию OSGi R4.2 DS - Declarative Service).
Это особенно верно, начиная с OSGi 4.2, потому что теперь намного проще писать компоненты DS как объекты POJO: методы activate и deactivate больше не требуются для возьмите параметр ComponentContext . См. Также Ленивая декларативная служба .

Примечание:

Это может помочь заменить эти термины в контексте OSGi и посмотреть, «как мы к этому пришли» ( отличное сообщение в блоге Нила Бартлетта ).

Вот некоторые важные экстракты, где «модули» в конечном итоге являются пакетами OSGi (управляющими компонентами, которые объявляют службы):

Разделение модулей

Наше первое требование - четко разделить модули, чтобы классы из одного модуля не имели неконтролируемая способность видеть и скрывать классы из других модулей .
В традиционной Java так называемый «путь к классам» - это огромный список классов, и если несколько классов имеют одно и то же полное имя, то всегда будет найден первый, а второй и все другие будут проигнорированы.

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

Уровень доступа к модулю

Если мы остановимся на этом, то модули будут полностью изолированы и не смогут взаимодействовать друг с другом. Чтобы сделать систему практичной, нам нужно снова добавить возможность видеть классы в других модулях, но мы делаем это осторожно и ограниченно.
На этом этапе мы вводим еще одно требование: модули хотели бы иметь возможность скрывать некоторые детали своей реализации.

Мы хотели бы иметь уровень доступа «модуль», но проблема сегодня в том, что компилятор javac не знает, где лежат границы модуля.

Решение, которое мы выбрали в нашей модульной системе, - разрешить модулям «экспортировать» только части своего содержимого. Если какая-то часть модуля не экспортируется, то другие модули просто не могут ее увидеть.

При импорте мы должны импортировать то, что нам действительно нужно использовать, независимо от того, откуда оно взято, и игнорировать все, что упаковано вместе с ним.

Детализация экспорта и импорта

OSGi выбирает пакеты.
Содержимое пакета Java должно быть в некоторой степени согласованным, но перечислить пакеты как импортируемые и экспортируемые - не слишком обременительно, и ничего не мешает поместить некоторые пакеты в один модуль и другие пакеты в другом модуле.
Код, который должен быть внутренним по отношению к нашему модулю, может быть помещен в один или несколько неэкспортированных пакетов.

Связывание пакетов

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

Затем он просматривал импортированные недавно установленные модули и пытался найти соответствующие экспорты.

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

Версии

Наша модульная система выглядит хорошо, но мы пока не можем справиться с изменениями, которые неизбежно происходят в модулях с течением времени. Нам нужно поддерживать версии.

Как мы это делаем? Во-первых, экспортер может просто указать некоторую полезную информацию об экспортируемых пакетах: «Это версия 1.0.0 API».Теперь импортер может импортировать только ту версию, которая совместима с тем, что он ожидает, и была скомпилирована / протестирована, и отказаться принимать

Модули упаковки и метаданные

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

Итак, единственный вопрос: куда мы должны поместить метаданные, то есть списки импорта и экспорта, версий и так далее?

Как оказалось, OSGi была разработана до 2000 года, поэтому она выбрала одно из этих решений. Вместо этого он посмотрел на спецификацию файла JAR, где был сформулирован ответ:
META-INF / MANIFEST.MF - стандартное расположение для произвольных метаданных, специфичных для приложения.

Позднее связывание

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

Мы должны искать децентрализованный подход .
Вместо того, чтобы получать указания от класса God, давайте предположим, что каждый модуль может просто создавать объекты и публиковать их где-нибудь, чтобы другие модули могли их найти. Мы называем эти опубликованные объекты «услугами», а место, где они публикуются, «реестром услуг».
Самая важная информация о службе - это интерфейс (или интерфейсы), который она реализует, поэтому мы можем использовать ее в качестве первичного регистрационного ключа.
Теперь модуль, которому необходимо найти экземпляры определенного интерфейса, может просто запросить реестр и узнать, какие службы доступны в данный момент. Сам реестр по-прежнему является центральным компонентом, существующим вне любого модуля, но это не «Бог»… скорее, это похоже на общую доску.