Является ли OSGi излишним для модульных веб-проектов?

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

Я рассматривал наложения Maven и OSGi как два варианта. Оверлеи Maven, как правило, занимают много времени при копировании ресурсов из базового оверлея. Я рассматривал Spring OSGi Web как вариант, потому что они, кажется, находятся на правильном пути для модульного разделения небольших фрагментов (контроллеры, представления, JS/ресурсы/изображения) для веб-проектов.

Является ли OSGi излишним? Это то, что мне нужно использовать? Есть ли что-то лучше?


person Matt    schedule 09.02.2011    source источник


Ответы (4)


OSGI отлично подходит, если вам нужно добавлять/удалять непредвиденные функции (и код) во время выполнения (а не просто включать или отключать их), но в большинстве случаев это не требуется для веб-приложений.

Поэтому в вашем случае я бы рекомендовал использовать конфигурацию (файл) для включения или отключения функций, если это возможно. Это также имеет то преимущество, что вам нужна только одна ВОЙНА.

Чтобы решить проблему: «как поместить файл конфигурации в WAR», у вас есть несколько способов ( in-a-maven-war-project">Разные файлы для упаковки в военный проект Maven ):

  • используйте среды maven - (хорошо, тогда у вас есть несколько WAR, но разница только в файле конфигурации, и процесс сборки становится не таким медленным, потому что для каждой среды выполняется только процесс упаковки WAR)
  • хранить конфигурацию вне WAR
  • сохранить конфигурацию за пределами WAR, например, в базе данных
person Ralph    schedule 09.02.2011
comment
Я не думаю, что окружающая среда является ответом. Я создаю не один WAR для многих сред с разными конфигурациями, а много разных WAR с разными функциями. Например, index.jsp и login.jsp могут быть общими для всех проектов, а profile.jsp — только для некоторых. - person Matt; 12.02.2011
comment
@Matt Fisher - подсказка об средах полезна только в сочетании с файлами конфигурации. Если у вас действительно есть причина вставлять и удалять исходный код, используйте osgi. - person Ralph; 12.02.2011

Вас могут заинтересовать Spring Slices. Это в основном позволяет вам иметь фрагменты веб-приложения, развернутые как отдельные пакеты. В зависимости от сложности вашего общего предложения это может быть желательно.

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

У кого есть более свежая информация, добавляйте ссылки.

http://blog.springsource.com/2009/08/07/slices-menu-bar-screencast/

person ptomli    schedule 09.02.2011
comment
Я тоже вкратце посмотрел на это. Я думаю, что Spring Slices — это правильное направление, позволяющее разработчикам выбирать, какие модули создавать проект/WAR. Подробнее об этом... - person Matt; 12.02.2011
comment
На самом деле это гораздо более впечатляюще, чем это. Вы разрабатываете функциональность своего сайта в отдельных пакетах, а затем можете развертывать/обновлять функции во время выполнения. Подумайте об обновлении раздела форума, в то время как раздел корзины и магазина продолжает работать. - person ptomli; 14.02.2011

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

person Augusto    schedule 09.02.2011
comment
Вот такая идея... Зачем мне включать страницы, контроллеры, изображения, скрипты и т. д. в WAR, которому они не нужны? Я не думаю, что модульность проекта (набора проектов) — это плохо — я ищу лучший способ сделать это. - person Matt; 12.02.2011

https://github.com/griddynamics/banshun, который представляет собой модульность без osgi для Spring, поддерживает два понятия: настройка. Он может собирать и создавать экземпляры модулей (дочерних контекстов) с помощью подстановочного знака, который называется настройкой времени сборки, подразумевая, что профиль maven помещает необходимые оверлеи в WAR. Обратным способом является кастомизация во время выполнения, когда необходимые модули определяются в соответствии со свойством.

person mkhludnev    schedule 01.09.2013