Как развернуть приложения OSGi и их зависимости?

Question

OSGi, похоже, имеет отличное преимущество, имея небольшие развертываемые артефакты, не заключая десятки JAR-зависимостей в каталог lib. Однако я не могу найти ничего, что подсказывало бы мне простой и надежный способ развертывания зависимостей в контейнере. Например, у меня есть приложение, которое использует CXF и несколько подпроектов Spring. Если мне нужно будет развернуть это приложение на новом сервере Glassfish, каков будет лучший способ сделать это, обеспечив установку всех зависимостей?

Я использую Maven, и может показаться , что может быть какой-то способ получить хук, который просматривает каталог META-INF / maven и извлекает список зависимостей из pom.xml и идет и выбирает необходимые библиотеки (вероятно, из местного репо). Есть ли способ сделать это?

Плагин Pax звучит так, как будто он это делает, но похоже, что он основан на обновлении контейнера Felix? Что не то, что я хочу, я имею дело с уже запущенным, удаленным контейнером.

Есть ли какой-нибудь кадр, такой как инструмент командной строки, в отличие от GUI?

Answer 1

Существует несколько способов развертывания зависимых пакетов в контейнеры OSGi.Вот некоторые из них:

1 Хранилище пакетов Felix OBR

Сначала необходимо создать файл индекса XML для доступных пакетов, используя такой инструмент, как bindex.Если вы используете maven-bundle-plugin, то он автоматически поддерживает индекс OBR в ~ / .m2 / repository / repository.xml.

Загрузка индекса с использованием интерфейса командной строки OBR:

> obr:addUrl file:/Users/derek/.m2/repository/repository.xml

Затем попросите OBR развернуть целевой пакет с зависимостями, определенными из индекса OBR:

> obr:deploy com.paremus.posh.sshd
Target resource(s):
-------------------
   Paremus Posh Ssh Daemon (1.0.23.SNAPSHOT)

Required resource(s):
---------------------
   Paremus Command API (1.0.23.SNAPSHOT)

Optional resource(s):
---------------------
   Paremus Config Admin Commands (1.0.23.SNAPSHOT)
   Paremus OSGi & LDAP Types (1.0.23.SNAPSHOT)

2 Apache Karaf

Karaf поддерживает «функции», которые в основномсписки пакетов, необходимых для предоставления функции:

karaf@root> features:info obr
Description of obr 2.0.0 feature
----------------------------------------------------------------
Feature has no configuration
Feature has no dependencies.
Feature contains followed bundles:
  mvn:org.apache.felix/org.apache.felix.bundlerepository/1.6.4
  mvn:org.apache.karaf.shell/org.apache.karaf.shell.obr/2.0.0
  mvn:org.apache.karaf.features/org.apache.karaf.features.obr/2.0.0

karaf@root> features:install obr

3 Eclipse Virgo

Дева использует планов для определения артефактов, составляющих приложение, и она может автоматическипредоставлять зависимости приложения, включая комплекты, планы, архивы планов (PAR) и конфигурации, как из локальных, так и из удаленных репозиториев.

4 Paremus Nimble

Nimble использует OBR (или его собственный расширенный) индексы репозитория для автоматического развертывания всех зависимых комплектов, необходимых для активации целевого комплекта (и удаления их при остановке целевого комплекта).Он также может обнаруживать другие зависимости, например, для комплекта WAB требуется веб-расширитель и автоматически устанавливать его в соответствии с настраиваемой политикой.

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

В приведенном ниже примере также показано, что поддержка ведения журнала автоматически устанавливается при активации sshd:

$ posh
________________________________________
Welcome to Paremus Nimble!
Type 'help' for help.
[denzil.0]% nim:add --dry-run com.paremus.posh.sshd@active
-- sorted parts to install --
4325   osgi.resolved.bundle/ch.qos.logback.core:0.9.22
-- start dependency loop --
5729   osgi.resolved.bundle/com.paremus.util.logman:1.0.23.SNAPSHOT
5727   osgi.active.bundle/com.paremus.util.logman:1.0.23.SNAPSHOT
3797   osgi.resolved.bundle/ch.qos.logback.classic:0.9.25.SNAPSHOT
3792   osgi.resolved.bundle/slf4j.api:1.6
-- end dependency loop --
436   osgi.resolved.bundle/org.apache.mina.core:2.0.0.RC1
6533   osgi.resolved.bundle/sshd-core:0.3
398   osgi.resolved.bundle/com.paremus.posh.sshd:1.0.23.SNAPSHOT
396   osgi.active.bundle/com.paremus.posh.sshd:1.0.23.SNAPSHOT

(отказ от ответственности: я являюсь разработчиком в Paremus)

5 Apache Felix Gogo

gogo - это новая стандартная оболочка командной строки RFC147.Он уже используется в Felix, Karaf, Nimble и скоро будет доступен в Glassfish.

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

Answer 2

Если вы создаете приложение OSGi и классическое приложение Java, которые делают одно и то же и используют одни и те же библиотеки, вам понадобится точно такой же набор JAR.Большим отличием является возможность явного определения ваших зависимостей (и, возможно, создания более детализированных JAR-файлов для вашего приложения).

Существует только один известный мне сервер на основе OSGi (Virgo Eclipse, ранее DM-сервер Spring),Glassfish и Websphere поддерживают OSGi, но я с ними не играл, поэтому сказать особо не могу.Что я могу сказать, так это то, что всем им требуется контейнер OSGi, и обычно это Eclipse Equinox или Apache Felix.

Похоже, ваш вопрос действительно касается подготовки приложения (разработка того, что необходимо развернуть).Я знаю, что для Maven 3.0 они проделали кучу вещей, работая с инфраструктурой обеспечения Eclipse P2.

Для вашего приложения вы развертываете EAR или WAR?Для любого из них ваша система сборки должна будет создать архив со всеми зависимостями, иначе он не будет работать.Это немного сбивает с толку, почему у вас есть проблема, потому что люди используют Maven, потому что он выполняет транзитивное управление зависимостями для своих сборок.

Answer 3

Существует фундаментальный аспект вашего вопроса, который еще не решен.

Glassfish действительно является полноценным сервером приложений, как и большинство современных серверов приложений: они предоставляют вам веб-контейнер (где вы будете развертывать WAR-архивы), контейнер Java EE ( развернуть EJB в архивах JAR и EAR), а также интегрировать контейнер OSGI . Последний затем используется для собственных внутренних механизмов запуска сервера приложений.

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

Есть несколько очень важных технических проблем, которые нельзя упускать из виду. (Я сосредотачиваюсь здесь на объективных и фактических соображениях, избегая любых субъективных решений, философии, стратегии и других контекстно-зависимых соображений, которые действительно могут также иметь большое значение для вашего окончательного решения):

1. Контейнер OSGI не предоставляет вам Неявное или декларативное Управление потоками , Постоянство или Управление транзакциями Сервисы, такие как Интернет и контейнеры Java EE. Итак, планируйте анализировать эти проблемы и создавать код для управления вашими потоками и, например, заниматься распространением транзакций по этим потокам. Конечно, OSGi предоставляет все необходимые API для работы с этими аспектами, но требует кодирования (где АОП может помочь). С другой стороны, в контейнерах Web и Java EE вы полагаетесь на управляемые контейнером службы и / или используете аннотации EJB, дескрипторы развертывания и управляемые сервером объекты, такие как пулы, чтобы просто объявить, сколько потоков вы хотите параллельно, размеры пулы соединений и какие атрибуты транзакций. Существуют преимущества и недостатки в любом стиле (процедурный в OSGi по сравнению с декларативным или неявный в серверах приложений Java).
2. OSGI обеспечивает упорядоченный способ загрузки вашего кода, управление зависимостями модуля , даже работу с несколькими сосуществующими версиями одной и той же модуль и динамически добавлять / удалять и запускать / останавливать так называемые комплекты (единицы развертывания OSGI), при условии, что действительно ваш комплект содержит логику для обработки потенциальных проблем запуска / остановки, таких как правильное прерывание все запущенные потоки на остановке - потоки, которые могли бы «распространяться» через другие зависимые модули. С другой стороны, контейнеры Java EE и Web часто содержат копии зависимых JAR-файлов, которые могут привести к более сложным развертываниям, если вы не начнете учитывать иерархию загрузчика классов вашего сервера приложений и использовать ее для развертывания «разделяемых библиотек». либо в виде простых файлов POJO, либо в виде Java EE-бинов, упакованных в файлы JAR. Как бы то ни было, в более поздних случаях управление зависимостями развертывания становится проблемой, которую вам придется решать как минимум в время сборки с использованием таких фреймворков, как Maven. Затем во время выполнения может потребоваться сценарий запуска / остановки каскадов в соответствии с зависимостями; в противном случае воспользуйтесь преимуществами определенных расширений сервера приложений, которые решают эти проблемы динамического развертывания в контейнерах Web и Java EE (например, Weblogic).
3. Как уже было сказано, OSGI теперь используется большинством серверов приложений для управления собственной последовательностью запуска . С ростом сложности платформ, умножением API, увеличением числа групп разработчиков для сборки одного конечного продукта, а также использованием множества сторонних компонентов / компонентов с открытым исходным кодом OSGI становится незаменимым запуском сервера инструмент для обеспечения стабильных выпусков и согласованного набора совместимых версий всех компонентов. Подумайте об Eclipse IDE: с каталогом тысяч плагинов и большим количеством новых выпусков эта IDE была бы очень хрупкой платформой без OSGI в качестве основы. Современные серверы приложений сталкиваются с той же проблемой.
4. Исходя из вышеизложенных соображений , вы можете испытать большой соблазн на layer вашего кода на некоторые средства, которые вы можете использовать на уровне OSGI, который, в свою очередь, предоставляет базовые сервисы для Java На уровне EE bean размещается бизнес-логика, а затем слой веб-сервлетов для взаимодействия с целым ... но всплывают два других вопроса: (a) Как заставить все эти компоненты взаимодействовать друг с другом? OSGI имеет свой собственный механизм хранилища, и развернутые API JAR не будут видны другим модулям, если они явно не опубликованы в OSGI. Контейнеры Web и Java EE используют совершенно разные технологии хранилища для доступа к интерфейсам компонентов друг друга, а именно JNDI. Опять же, посмотрите на документацию по вашему конкретному серверу приложений, которая может предоставить средства для обращения к компонентам Java EE из комплектов OSGI и наоборот (например, Glassfish, начиная с V3); но будьте осторожны с управлением потоками и областями транзакций. (b) Как бы вы не вмешивались в последовательность запуска сервера приложений? OSGI имеет тенденцию становиться основным компонентом системы (под управлением поставщика) по сравнению с Web и Java Контейнеры EE естественно ориентированы на размещение кода вашего приложения (под вашим управлением). Обновление сервера приложений или установка новой версии могут помешать вашим собственным развертываниям OSGI; вам придется проверить проблему и, как следствие, организовать свои сценарии развертывания.

Вопрос богат и его анализ сложен. Дальнейшее рассмотрение должно учитывать характер приложения для сборки. Более того, если вы намереваетесь использовать среды разработки, такие как Spring Source и / или Camel с открытым исходным кодом, а также специфичные для вендора среды, такие как Oracle Fusion SOA, JBoss Switchyard и т. Д., У вас будет много других технических ограничений, которые необходимо учитывать.

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

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