Встроенный OSGi или пакет приложений

Question

Я только что провел последние два дня, читая все материалы по OSGi, которые я могу взять в руки, и, наконец, думаю, что обдумал это.

Сейчас я пытаюсь интегрировать его с существующим приложением по многим причинам, таким как сторонние плагины, автоматические обновления, не говоря уже о том, что SOA просто делает меня счастливым.

Теперь у меня есть решение, которое я изо всех сил пытаюсь принять - погода

1. Все мое приложение должно стать пакетом OSGi, установленным по умолчанию в контейнере; или
2. Мое приложение должно запустить встроенный контейнер OSGi и взаимодействовать с ним для всех подключенных сервисов.

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

Answer 1

для варианта 1) вы действительно не хотите, чтобы все ваше приложение было в одном комплекте - вы потеряете все преимущества OSGi - но на самом деле это зависит от размера вашего приложения.

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

в варианте 1) вам нужно включить какой-нибудь пакет http / servlet (существует мост, который существует) в варианте 2) ваше приложение может работать на сервере приложений, поэтому вам не нужно об этом беспокоиться.

Первый вопрос, который вы хотите задать себе, касается рабочей среды. Кто собирается запустить приложение? Нужно ли им / хотят пройти обучение по OSGi? Они более удобны со стеком J2EE?

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

Я бы посоветовал не слишком беспокоиться о времени выполнения OSGi - но начинать с разработки OSGi - ничто не мешает вам разрабатывать «стиль OSGi» и работать в стандартной среде JRE.

Answer 2

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

Answer 3

Я думаю, что вы хотите использовать опцию 1, и ваше приложение должно состоять из набора пакетов внутри (в основном из коробки) контейнера OSGi.

1. Это улучшит модульность вашего собственного кода. Вы даже можете обнаружить, что некоторые его части могут предоставлять услуги использования за пределами исходного приложения.
2. Гораздо проще использовать другие пакеты из OSGi, чем из хост-приложения. Поскольку хост-приложение не может видеть классы комплектов (а комплекты могут видеть только то, что вы явно представляете с хоста), вы должны установить довольно запутанный путь к классам или прибегнуть к отражению для вызова комплектов извне контейнера.

Так что я бы сказал, что даже в краткосрочной перспективе вариант 1, вероятно, проще.

Кроме того, я согласен с утверждением Патрика о том, что большая часть вашего кода не должна заботиться о том, работает ли он в OSGi или в простой JVM. Особенно при использовании декларативных сервисов и т. Д. Необходимость использования интерфейсов и механизмов OSGi из вашего кода значительно уменьшается: вы просто добавляете несколько файлов дескрипторов в META-INF jar.

Answer 4

Я бы определенно рекомендовал 1 - приложение должно стать пакетом OSGi, и не только из-за простого обновления. Если половина вашего кода находится в платформе OSGi, а половина - снаружи, вам придется построить мост для связи между двумя половинами; у вас также могут возникнуть проблемы с видимостью классов.

Есть также много преимуществ от 1, и это не так сложно достичь. Я бы порекомендовал следующее:

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

Вы не обязаны иметь много модулей - OSGi может так же легко обрабатывать два пакета по 10 МБ каждый, а также 100 небольших пакетов. Разделение должно быть результатом самой функциональности - хорошей отправной точкой является диаграмма архитектуры UML, которую вы, вероятно, сделали еще до того, как приступили к реализации. Места, где различные функциональные части взаимодействуют друг с другом, - это как раз те места, где вы должны подумать об определении интерфейсов вместо классов - и эти интерфейсы станут вашими сервисами OSGi, а реализации станут связками - и в следующий раз у вас будет обновив какую-то часть, вы обнаружите, что гораздо проще предсказать влияние на другие части приложения, потому что вы четко отделили его и объявили его в манифесте комплектов.

• Разделяйте любые внешние / открытые библиотеки, которые вы используете, в отдельных пакетах. Скорее всего, они будут частями, которые нужно будет обновлять чаще и на другой временной шкале, чем ваш собственный код. Здесь также важнее определить четкие зависимости пакетов, версии пакетов и избегать зависимости от частей реализации, а не только от интерфейсов!

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

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

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

Answer 5

Вы смотрели на сервер приложений Spring? Разве это не позволяет вам управлять этим материалом?