Как развернуть приложения и зависимости 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 Затмение Дева

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

4 Paremus Limble

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 (Eclipse's Virgo, ранее Spring Server от DM). 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 не предоставляет вам неявных или декларативных службуправленияпотоками, постоянства или управления транзакциями, таких как контейнеры Web и Java EE. Итак, планируйте анализировать эти проблемы и создавать код для управления вашими потоками и, например, заниматься распространением транзакций по этим потокам. Конечно, OSGi предоставляет все необходимые API для работы с этими аспектами, но требует кодирования (где АОП может помочь). С другой стороны, в контейнерах Web и Java EE вы полагаетесь на службы, управляемые контейнером, и / или используете аннотации EJB, дескрипторы развертывания и управляемые сервером объекты, такие как пулы, чтобы просто объявить, сколько потоков вы хотите параллельно, размеры пулы соединений и какие атрибуты транзакции. Существуют преимущества и недостатки в любом стиле (процедурный в OSGi по сравнению с декларативным или неявный в серверах приложений Java).
2. OSGI обеспечивает упорядоченный способ загрузки вашего кода, управления зависимостями модулей, даже работы с несколькими сосуществующими версиями одного и того же модуля, а также динамического добавления / удаления и запуска / остановки так называемых пакетов (модулей развертывания OSGI), при условии, что ваш пакет действительно содержит логика для обработки потенциальных проблем запуска / остановки, таких как правильное прерывание всех запущенных потоков на остановке - потоки, которые могли бы "распространяться" через другие зависимые модули. С другой стороны, контейнеры Java EE и Web часто содержат копии зависимых JAR-файлов, которые могут привести к более сложным развертываниям, если вы не начнете рассматривать иерархию загрузчика классов вашего сервера приложений и использовать ее для развертывания "разделяемых библиотек" в виде простых JAR-файлов POJO, или как бобы Java EE, упакованные в JAR. В любом случае, в более поздних случаях управление зависимостями развертывания становится проблемой, с которой вам придется столкнуться, по крайней мере, во время сборки с использованием таких платформ, как Maven. Затем во время выполнения может потребоваться сценарий запуска / остановки каскадов в соответствии с зависимостями; в противном случае воспользуйтесь преимуществами конкретных расширений сервера приложений, которые решают эти проблемыдинамического развертывания в контейнерах Web и Java EE (например, Weblogic).
3. Как уже было сказано, OSGI теперь используется большинством серверов приложений для управления собственной последовательностью запуска. С ростом сложности платформ, умножением API, увеличением числа групп разработчиков для сборки единого конечного продукта, а также использованием множества сторонних компонентов / компонентов с открытым исходным кодом OSGI становится незаменимымсредством запуска сервера, чтобы обеспечить стабильные выпуски и согласованный набор совместимых версий всех компонентов. Подумайте об Eclipse IDE: с каталогом из тысяч плагинов и большим количеством новых выпусков эта IDE была бы очень хрупкой платформой без OSGI в качестве основы. Современные серверы приложений сталкиваются с той же проблемой.
4. Исходя из вышеизложенных соображений, у вас может возникнуть искушение разделить ваш код на некоторые средства, которые вы могли бы использовать на уровне OSGI, который, в свою очередь, предоставляет базовые услуги для уровня бизнес-логики уровня Java EE, в котором размещается бизнес-логика, а затем - для уровня веб-сервлета для интерфейса в целом... но всплывают два других вопроса: (а) Как вы заставляете все эти компоненты взаимодействовать вместе? OSGI имеет собственный механизм хранилища, и развернутые API JAR не будут видны другим модулям, если они явно не опубликованы в OSGI. Контейнеры Web и Java EE используют совершенно разные технологии хранилища для доступа к интерфейсам компонентов друг друга, а именно JNDI. Опять же, посмотрите на документацию по вашему конкретному серверу приложений, которая может предоставить средства для обращения к компонентам Java EE из комплектов OSGI и наоборот (например, Glassfish, начиная с V3); но будьте осторожны с управлением потоками и областями транзакций. (б) Как бы вы не вмешивались в последовательность запуска сервера приложений? OSGI имеет тенденцию становиться основным компонентом системы (под управлением поставщика) по сравнению с контейнерами Web и Java EE, естественно ориентированными на размещение кода вашего приложения (под вашим управлением). Обновление сервера приложений или установка новой версии могут помешать вашим собственным развертываниям OSGI; вам придется проверить проблему и, как следствие, организовать свои сценарии развертывания.

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

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

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