Вы совершенно правы, полагая, что здесь есть синергия, у нас есть модульное веб-приложение, в котором само приложение собирается автоматически из независимых компонентов (пакетов OSGi), где каждый пакет вносит свои собственные страницы, ресурсы, CSS и, возможно, javascript.
Мы не используем JSF (здесь Spring MVC), поэтому я не могу комментировать дополнительную сложность этой структуры в контексте OSGi.
Большинство фреймворков или подходов по-прежнему придерживаются «старого» образа мышления: один файл WAR, представляющий ваше веб-приложение, а затем множество пакетов и сервисов OSGi, но почти никто не занимается модуляризацией самого графического интерфейса.
Предпосылки для дизайна
При использовании OSGi первый вопрос, который необходимо решить: каков ваш сценарий развертывания и кто является основным контейнером? Я имею в виду, что вы можете развернуть свое приложение в среде выполнения OSGi и использовать ее инфраструктуру для всего. В качестве альтернативы вы можете встроить среду выполнения OSGi в традиционный сервер приложений, и тогда вам нужно будет повторно использовать некоторую инфраструктуру, в частности, вы хотите использовать механизм сервлетов AppServer.
В настоящее время наша конструкция основана на OSGi в качестве контейнера, и мы используем HTTPService, предлагаемый OSGi, в качестве контейнера сервлетов. Мы планируем создать своего рода прозрачный мост между внешним контейнером сервлетов и OSGi HTTPService, но эта работа продолжается.
Архитектурный эскиз модульного веб-приложения Spring MVC + OSGi
Таким образом, цель состоит не только в обслуживании веб-приложения через OSGi, но и в применении компонентной модели OSGi к самому веб-интерфейсу, чтобы сделать его компонуемым, повторно используемым, динамическим.
Это компоненты в системе:
- 1 центральный пакет, который заботится о соединении Spring MVC с OSGi, в частности, он использует код Бернда Колба, чтобы вы могли зарегистрировать Spring DispatcherServlet в OSGi в качестве сервлета.
- 1 настраиваемый сопоставитель URL-адресов, который вводится в 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 и ее превосходной компонентной модели, чтобы действительно позволить проектировать компонентные веб-приложения.
person
Boris Terzic
schedule
24.09.2008
