То, что вы хотите сделать, звучит выполнимо, с несколькими оговорками:
Слой вида: Во-первых, ваш слой вида звучит немного перегруженным. Существуют и другие способы модуляции компонентов JSF с использованием пользовательских компонентов, которые позволяют избежать головной боли, связанной с попыткой создать нечто столь же драматичное, как управляемые bean-компоненты с поздним связыванием.
Сами модули: Во-вторых, ваши модули не кажутся особенно модульными. Ваш первый маркированный список звучит так, как будто вы пытаетесь создать совместимые веб-приложения, а не модули как таковые. Моя идея модуля заключается в том, что каждый компонент имеет четко определенную и более или менее дискретную цель. Например, как ex лежит в основе vi . Если вы идете по маршруту OSGi, то мы должны определить модульное, как это: Модульное, ради этого обсуждения, означает, что компоненты могут быть заменены в горячем режиме, то есть их можно добавить и удалено без нарушения работы приложения.
Зависимости: Меня немного беспокоит ваше описание модулей как "возможно зависящих друг от друга". Возможно, вы (я надеюсь) уже знаете это, но ваши зависимости должны сформировать ориентированный ациклический граф. После того, как вы введете круговую зависимость, вы попросите обидеть мир с точки зрения возможной ремонтопригодности приложения. Одним из самых больших недостатков OSGi является то, что он не не предотвращает циклические зависимости, так что вам решать, как это сделать. В противном случае ваши зависимости будут расти как кудзу и постепенно душат остальную часть экосистемы вашей системы.
Сервлеты: Fuhgeddaboudit. Вы не можете позднее связывать сервлеты с веб-приложением, пока не будет запущена спецификация Servlet 3.0 (как указал Паскаль). Чтобы запустить отдельный служебный сервлет, вам нужно поместить его в собственное приложение.
ОК, очень много предостережений. Давайте подумаем о том, как это может работать:
Вы определили свой собственный модуль JSF, чтобы делать ... что именно? Давайте дадим ему определенную, довольно тривиальную цель: экран входа в систему. Итак, вы создаете свой экран входа в систему, позднее связываете его с помощью OSGi в своем приложении и ... что дальше? Как приложение узнает о функциональности входа в систему, если вы не определили ее на своей странице .jspx? Как приложение узнает, что оно находится там, где оно не может знать?
Есть способы обойти это с помощью условных включений и тому подобного (например, <c:if #{loginBean.notEmpty}>), но, как вы сказали, вещи становятся немного затруднительными, когда ваш управляемый loginBean существует в другом модуле, который, возможно, даже не был представлен в приложение еще. Фактически, вы получите исключение сервлета, если этот loginBean не существует. Так что ты делаешь?
Вы определяете API в одном из ваших модулей. Все управляемые bean-компоненты, которые вы собираетесь совместно использовать между модулями, должны быть указаны как интерфейсы на этом уровне API. И все ваши модули должны иметь реализации по умолчанию любого из этих интерфейсов, которые они намерены использовать. И этот API должен быть общим для всех совместимых модулей. Затем вы можете использовать OSGi и Spring, чтобы связать вместе указанные компоненты с их реализацией.
Мне нужно уделить время, чтобы указать, что я не подхожу к этой проблеме. Не за что. Учитывая что-то вроде простой страницы входа в систему или даже такой сложной, как график акций, я лично предпочел бы создать собственный компонент JSF. Но если требование «я хочу, чтобы мои управляемые bean-компоненты были модульными (т. Е. С возможностью горячей замены и т. Д.)», Это единственный известный мне способ заставить его работать. И я даже не совсем уверен, что будет работать. Этот обмен электронной почтой предполагает, что это проблема, над которой разработчики JSF только начали работать.
Обычно я рассматриваю управляемые bean-компоненты как часть уровня представления, и поэтому использую их только для логики представления и делегирую все остальное на уровень обслуживания. По моему мнению, создание управляемых bean-компонентов с поздним связыванием - это продвижение их из уровня представления в бизнес-логику. Есть причина, по которой все эти учебные пособия сосредоточены на службах: потому что большую часть времени вы хотите подумать о том, что потребуется приложению для запуска «без головы», и насколько легко было бы «убрать» ваш взгляд, если, для Например, вы хотели, чтобы он работал со всеми его функциями на телефоне Android.
Но, похоже, многое из того, с чем вы работаете, это сама логика представления - например, необходимость поменять местами другой шаблон представления. OSGi / Spring должна быть в состоянии помочь, но вам нужно что-то в вашем приложении, чтобы выбирать между доступными реализациями: почти то, для чего был создан OSGi Service Registry.
Это оставляет статические ресурсы. Вы можете модулировать их, но помните, что вам нужно определить интерфейс для извлечения этих ресурсов, и вам нужно будет обеспечить реализацию по умолчанию, чтобы ваше приложение не задыхалось, если они отсутствуют. Если i18n является соображением, это может быть хорошим способом. Если вы хотите быть действительно предприимчивым, то вы можете поместить свои статические ресурсы в JNDI. Это сделало бы их полностью горячей заменой и избавило бы вас от необходимости пытаться решить, какую реализацию использовать программно, но есть некоторые недостатки: любой неудачный поиск приведет к тому, что ваше приложение вызовет исключение NamingException. И это излишне. JNDI обычно используется в веб-приложениях для конфигурации приложений.
Что касается оставшихся вопросов:
Я изобретаю здесь велосипед? Существуют ли стандартные решения для этого?
Ты немного. Я видел приложения, которые делают это вида , но вы, похоже, натолкнулись на довольно уникальный набор требований.
Как вы думаете, OSGi - подходящая технология для описанной задачи?
Если вам нужна горячая замена модулей, тогда вы можете выбрать OSGi и облегченный интерфейс ServiceLocator.
Является ли мой эскиз приложения OSGI более или менее правильным?
Я не могу сказать, не зная больше, где находятся границы ваших компонентов. На данный момент, похоже, вы заставляете OSGi делать больше, чем он способен.
Но не верьте мне на слово. I найдено прочее материалы для чтения в этих местах.
И поскольку вы спрашиваете о Spring Slices, этого должно быть достаточно, чтобы вы начали . Вам понадобится Git-клиент, и, похоже, вы будете изучать приложение, просматривая исходный код. И это очень ранний прототип кода.