Начало работы с osgi, интересно, что такое концептуальная разница между пучками и компонентами. И когда использовать какие из них. Любые указатели приветствуются.
EDIT:
Компоненты и связки предоставляют разные интерфейсы и, следовательно, они, вероятно, не взаимозаменяемы
В терминологии OSGi "компонент" похож на службу времени выполнения. Каждый компонент имеет класс реализации и может опционально реализовать публичный интерфейс, эффективно предоставляя этот "сервис". Этот аспект OSGi иногда сравнивается с шаблоном реестра службы.
Компоненты в OSGi, по определению, предоставляются пакетом. Пакет может содержать/предоставлять несколько компонентов. Хотя сам по себе пакет не может предоставлять услугу, компоненты/декларативные службы используются, чтобы сделать OSGi более ориентированной на обслуживание. Вы не обязаны использовать компоненты/услуги.
A component:
Короче:
У пучка может быть только один активатор (требуется BundleContext) и может иметь столько активных компонентов, сколько хотите.
Это означает, что вы можете в конечном итоге попытаться вставить в один активатор несколько проблем, связанных с проблемой, в один класс.
Вот почему может быть проще управлять этими компонентами Declarative Services через SCR ( "Время выполнения служебных компонентов", которое является "пакетом расширителя", реализующим новую и улучшенную спецификацию DS-декларативной службы OSGi R4.2).
Это особенно актуально, поскольку OSGi 4.2, поскольку теперь гораздо проще записывать компоненты DS как POJO: методы activate и deactivate больше не нужны для принятия параметра ComponentContext. См. Также Lazy Declarative Service.
Примечание:
Он может помочь заменить эти термины в контексте OSGi и посмотреть "как мы туда попали" (отличное сообщение в блоге от Neil Bartlett)
Вот некоторые соответствующие выдержки, в которых "модули" становятся связями OSGi (управляющие компоненты, объявляющие сервисы):
Нашим первым требованием является чистое разделение модулей, чтобы классы из одного модуля не имели неконтролируемой способности видеть и скрывать классы из других модулей.
В традиционной Java так называемый "classpath" - это огромный список классов, и если у нескольких классов есть одно и то же полное имя, то первое будет всегда найдено, а второе и все остальные будут проигнорированы.Способ предотвращения неконтролируемой видимости и скрытия классов заключается в создании загрузчика классов для каждого модуля. Загрузчик классов может загружать только те классы, о которых он знает напрямую, что в нашей системе будет содержимым одного модуля.
Если мы остановимся здесь, то модули будут полностью изолированы и не смогут общаться друг с другом. Чтобы сделать систему практичной, нам нужно добавить возможность видеть классы в других модулях, но мы делаем это осторожным и ограниченным образом.
На этом этапе мы вводим другое требование: модули хотели бы скрыть некоторые из их деталей реализации.Мы хотели бы иметь уровень доступа к "модулю", но сегодня проблема заключается в том, что компилятор javac не знает, где лежат границы модуля.
Решение, которое мы выбираем в нашей модульной системе, - это позволить модулям "экспортировать" только части их содержимого. Если какая-то часть модуля не экспортируется, то он просто не может быть замечен другими модулями.
При импорте мы должны импортировать то, что нам действительно нужно использовать, независимо от того, откуда оно происходит, и игнорировать все вещи, которые упаковываются вместе с ним.
OSGi выбирает пакеты.
Содержимое пакета Java должно быть несколько согласованным, но не слишком тяжело перечислить пакеты как импорт и экспорт, и он не сломает ничего, чтобы поместить некоторые пакеты в один модуль и другие пакеты в другой модуль.
Код, который должен быть внутренним для нашего модуля, может быть помещен в один или несколько неэкспортированных пакетов.
Теперь, когда у нас есть модель для того, как модули изолируются и затем снова соединяются, мы можем представить себе создание структуры, которая строит конкретные экземпляры выполнения этих модулей. Он будет отвечать за установку модулей и создание классов загрузчиков, которые знают о содержании своих соответствующих модулей.
Затем он будет искать импорт вновь установленных модулей и пытается найти соответствующий экспорт.
Неожиданным преимуществом этого является возможность динамической установки, обновления и удаления модулей. Установка нового модуля не влияет на те модули, которые уже разрешены, хотя он может разрешить некоторые ранее неразрешимые модули. При удалении или обновлении фреймворк точно знает, какие модули затронуты, и при необходимости изменит свое состояние.
Наша модульная система выглядит неплохо, но мы пока не можем справиться с изменениями, которые неизбежно происходят в модулях с течением времени. Нам нужно поддерживать версии.
Как мы это делаем? Во-первых, экспортер может просто указать некоторую полезную информацию о экспортируемых пакетах: "это версия 1.0.0 API". Импортер теперь может импортировать только версию, которая совместима с тем, что она ожидает, и была скомпилирована/протестирована против, и отказывается принимать
Наша модульная система будет нуждаться в способе упаковки содержимого модуля вместе с метаданными, описывающими импорт и экспорт, в развертываемую единицу.
Итак, единственный вопрос: где мы должны помещать метаданные, т.е. списки импорта и экспорта, версии и т.д.?
Как бы то ни было, OSGi был разработан до 2000 года, поэтому он выбрал одно из этих решений. Вместо этого он снова посмотрел на спецификацию файла JAR, где был прописан ответ:
META-INF/MANIFEST.MF- стандартное расположение для произвольных метаданных приложения.
Последняя часть головоломки модульности - это поздняя привязка реализаций к интерфейсам. Я бы сказал, что это важная особенность модульности, хотя некоторые системы модулей игнорируют ее полностью или, по крайней мере, считают ее недоступной.
Мы должны искать децентрализованный подход.
Предположим, что каждый модуль может просто создавать объекты и публиковать их где-нибудь, чтобы другие модули могли их найти. Мы называем эти опубликованные объекты "сервисами" и местом, где они публикуются "реестр служб".
Наиболее важной информацией об услуге является интерфейс (или интерфейсы), который он реализует, поэтому мы можем использовать это как основной регистрационный ключ.
Теперь модуль, нуждающийся в поиске экземпляров определенного интерфейса, может просто запросить реестр и выяснить, какие службы доступны в это время. Сам реестр по-прежнему является центральным компонентом, существующим вне любого модуля, но это не "Бог"... скорее, это похоже на общую доску.