Вы совершенно правы, считая, что здесь есть синергизм, у нас есть модульное веб-приложение, в котором само приложение автоматически собирается из независимых компонентов (пакетов OSGi), где каждый пакет предоставляет свои собственные страницы, ресурсы, CSS и, возможно, JavaScript.
Мы не используем JSF (здесь Spring MVC), поэтому я не могу комментировать дополнительную сложность этой инфраструктуры в контексте OSGi.
Большинство фреймворков или подходов по-прежнему придерживаются «старого» мышления: один WAR-файл, представляющий ваше веб-приложение, а затем множество пакетов и сервисов OSGi, но почти ни один из них не занимается модульностью самого GUI.
Предпосылки для дизайна
С OSGi первый вопрос, который нужно решить: каков ваш сценарий развертывания и кто является основным контейнером? Я имею в виду, что вы можете развернуть свое приложение во время выполнения OSGi и использовать его инфраструктуру для всего. Кроме того, вы можете встроить среду выполнения OSGi в традиционный сервер приложений, а затем вам потребуется повторно использовать некоторую инфраструктуру, в частности, вы хотите использовать механизм сервлетов AppServer.
Наш дизайн в настоящее время основан на OSGi в качестве контейнера, и мы используем HTTPService, предлагаемый OSGi, в качестве нашего контейнера сервлета. Мы ищем какой-то прозрачный мост между внешним контейнером сервлета и OSTG HTTPService, но эта работа продолжается.
Архитектурный очерк модульного веб-приложения Spring MVC + OSGi
Таким образом, цель состоит не только в том, чтобы обслуживать веб-приложение поверх OSGi, но и в том, чтобы также применить компонентную модель OSGi к самому веб-интерфейсу, чтобы сделать его составным, повторно используемым, динамичным.
Это компоненты системы:
- 1 центральный пакет, который заботится о соединении Spring MVC с OSGi, особенно он использует код Бернда Колба , чтобы позволить вам зарегистрировать Spring DispatcherServlet с OSGi в качестве сервлета.
- 1 пользовательский URL Mapper, который внедряется в DispatcherServlet и обеспечивает сопоставление входящих HTTP-запросов с правильным контроллером.
- 1 центральный JSP-декоратор на основе Sitemesh, который определяет глобальный макет сайта, а также центральные библиотеки CSS и Javascript, которые мы хотим предложить по умолчанию.
Каждый пакет, который хочет добавить страницы в наш веб-интерфейс, должен опубликовать 1 или более контроллеров в качестве служб OSGi и обязательно зарегистрировать свой собственный сервлет и свои собственные ресурсы (CSS, JSP, изображения и т. Д.). ) с сервисом OSGi HTTPService. Регистрация выполняется с помощью HTTPService, а ключевые методы:
httpService.registerResources ()
а также
httpService.registerServlet ()
Когда пакет, вносящий вклад в веб-интерфейс, активирует и публикует свои контроллеры, они автоматически выбираются нашим центральным пакетом веб-интерфейса, и вышеупомянутый настраиваемый сопоставитель URL-адресов собирает эти службы контроллера и сохраняет актуальную карту URL-адресов для экземпляров контроллера.
Затем, когда приходит HTTP-запрос для определенного URL-адреса, он находит связанный контроллер и отправляет запрос туда.
Контроллер выполняет свою работу, а затем возвращает любые данные, которые должны быть обработаны и имя представления (в нашем случае JSP). Этот JSP находится в комплекте контроллера и может быть доступен и обработан центральным пакетом веб-интерфейса именно потому, что мы пошли и зарегистрировали расположение ресурса в HTTPService. Наш централизованный распознаватель затем объединяет этот JSP с нашим центральным декоратором Sitemesh и выплевывает полученный HTML-код клиенту.
Насколько нам известно, это довольно высокий уровень, но без полной реализации его сложно объяснить полностью.
Нашей ключевой целью для этого было посмотреть , что сделал Бернд Колб со своим примером преобразования JPetstore в OSGi, и использовать эту информацию для проектирования нашей собственной архитектуры.
ИМХО, в настоящее время слишком много шумихи и упора на то, чтобы каким-то образом встроить OSGi в традиционные приложения на основе Java EE, и очень мало мыслей о том, чтобы реально использовать идиомы OSGi и его превосходную модель компонентов, чтобы действительно позволить проектировать составные веб-компоненты. приложения.