Модульные веб-приложения

Недавно я изучал OSGi и думаю, что это выглядит действительно хорошей идеей для модульных приложений Java.

Однако мне было интересно, как OSGi будет работать в веб-приложении, где вам не нужно просто беспокоиться о коде - также HTML, изображения, CSS, что-то типа.

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

Я не уверен, что это имеет значение, но мы используем JSF и IceFaces (что добавляет еще один уровень проблем потому что у вас есть правила навигации, и вам нужно указать все файлы конфигурации лиц в вашем web.xml... doh!)

Изменить: согласно этот поток, файлы faces-config.xml могут быть загружены из файлов JAR - так что на самом деле возможно иметь несколько файлов faces-config.xml, не изменяя файл web.xml, если вы разделились на файлы JAR.

Приветствуются любые предложения: -)

Ответы

Ответ 1

Вы правы, думая, что здесь есть синергия. У нас есть модульное веб-приложение, в котором само приложение собирается автоматически из независимых компонентов (пакетов OSGi), где каждый комплект вносит свои собственные страницы, ресурсы, css и, возможно, javascript.

Мы не используем JSF (Spring MVC здесь), поэтому я не могу прокомментировать добавленную сложность этой структуры в контексте OSGi.

Большинство фреймворков или подходов по-прежнему придерживаются "старого" образа мышления: один WAR файл, представляющий ваш webapp, а затем множество пакетов и сервисов OSGi, но почти никто не заботится о модуляции самого GUI.

Предпосылки для дизайна

В OSGi первый вопрос для решения: каков ваш сценарий развертывания и кто является основным контейнером? Я имею в виду, что вы можете развернуть свое приложение во время работы OSGi и использовать его инфраструктуру для всего. Кроме того, вы можете внедрить среду выполнения OSGi на традиционном сервере приложений, а затем вам нужно будет повторно использовать некоторую инфраструктуру, в частности, вы хотите использовать механизм сервлетов AppServer.

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

Архитектурный эскиз Spring MVC + OSGi модульный webapp

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

Это компоненты в системе:

  • 1 центральное связывание, которое заботится о мостинге Spring MVC с OSGi, в частности использует код Bernd Kolb, чтобы вы могли зарегистрировать Spring DispatcherServlet с OSGi в качестве сервлета.
  • 1 настраиваемый URL-адрес Mapper, который вводится в DispatcherServlet и который обеспечивает сопоставление входящих HTTP-запросов с правильным контроллером.
  • 1 центральный дизайнер JSP на основе Sitemesh, который определяет глобальный макет сайта, а также центральные библиотеки CSS и Javascript, которые мы хотим предложить по умолчанию.

  • Каждый пакет, который хочет внести страницы в наш веб-интерфейс, должен опубликовать 1 или несколько контроллеров в качестве служб OSGi и убедиться, что зарегистрировать свой собственный сервлет и свои собственные ресурсы (CSS, JSP, изображения и т.д.). ) с OSGi HTTPService. Регистрация выполняется с помощью HTTPService, а ключевыми методами являются:

    httpService.registerResources() а также httpService.registerServlet()

Когда веб-узел, входящий в состав ui, активирует и публикует свои контроллеры, они автоматически подбираются нашим центральным веб-узлом ui, и вышеупомянутый настраиваемый URL-адрес Mapper собирает эти службы Controller и хранит обновленную карту URL-адресов для экземпляров контроллера.

Затем, когда HTTP-запрос поступает на определенный URL-адрес, он находит связанный контроллер и отправляет запрос там.

Контроллер выполняет свою работу, а затем возвращает любые данные, которые должны отображаться и имя представления (JSP в нашем случае). Этот JSP находится в пакете Controller и может быть доступен и передан центральным веб-узлом ui именно потому, что мы пошли и зарегистрировали местоположение ресурса с помощью HTTPService. Затем наш центральный разрешитель объединяет этот JSP с нашим центральным дизайнером Sitemesh и выплескивает полученный HTML-код клиенту.

Знайте, что это довольно высокий уровень, но без полной реализации он не может полностью объяснить.

Наш ключевой учебный момент для этого состоял в том, чтобы посмотреть то, что сделал Бернд Колб с его примером преобразования JPetstore в OSGi и использовать эту информацию для разработки наша собственная архитектура.

IMHO в настоящее время слишком много шумихи и сосредоточиться на том, чтобы OSGi каким-то образом встроена в традиционные приложения на основе Java EE, и очень мало думают о том, что они действительно используют идиомы OSGi и ее отличную компонентную модель, чтобы действительно разрешить дизайн компонентной сети приложения.

Ответ 2

Отъезд SpringSource dm Server - сервер приложений, построенный полностью с точки зрения OSGi и поддерживающий модульные веб-приложения. Он доступен в бесплатной версии с открытым исходным кодом и в коммерческих версиях.

Вы можете начать с развертывания стандартного файла WAR, а затем постепенно разбить приложение на модули OSGi или "пакеты" в OSGi-talk. Как вы можете ожидать от SpringSource, сервер отлично поддерживает фреймворк Spring и связанные с ним продукты портфеля Spring.

Отказ от ответственности: я работаю над этим продуктом.

Ответ 3

Имейте в виду сервер Spring DM licensing.

Ответ 4

Мы использовали Restlet с хорошим эффектом в OSGi со встроенной службой Http (под обложками на самом деле Jetty, но tomcat также доступен).

Restlet имеет нулевые и минимальные требования к конфигурации XML, и любая конфигурация, которую мы делаем, находится в BundleActivator (регистрируя новые службы).

При создании страницы мы просто обрабатываем соответствующие сервисные реализации для генерации вывода, стиля декоратора. Новые связки, подключаемые к сети, добавят новые украшения/виджеты страниц в следующий раз после их рендеринга.

REST дает нам хорошие чистые и значимые URL-адреса, множественные представления одних и тех же данных и кажется расширяемой метафорой (несколько глаголов, много существительных).

Бонусной особенностью для нас была обширная поддержка кеширования, в частности ETag.

Ответ 7

Взгляните на http://www.ztemplates.org, который прост и прост в освоении. Это позволяет помещать все связанные шаблоны, javascript и css в одну банку и использовать ее прозрачно. Это означает, что вам даже не нужно объявлять необходимый javascript на вашей странице при использовании предоставленного компонента, поскольку инфраструктура делает это для вас.

Ответ 8

Интересный набор сообщений. У меня есть веб-приложение, которое настраивается на основе клиента. Каждый клиент получает основной набор компонентов и дополнительных компонентов в зависимости от того, для чего они подписались. Для каждой версии мы должны "собрать" правильный набор сервисов и применить правильную конфигурацию меню (мы используем меню расположений) на основе клиента, что является утомительным, если не сказать больше. В основном это одна и та же база кода, но мы просто настраиваем навигацию, чтобы выставлять или скрывать определенные страницы. Это, очевидно, не идеально, и мы хотели бы использовать OSGi для интеграции сервисов. Хотя я вижу, как это делается для API-интерфейсов служб и как понять, как могут быть объединены ресурсы, такие как CSS и java script, и контроллеры (мы используем Spring MVC), как бы вы занимались "перекрестным разрезом", проблемы, связанные с навигацией по страницам и общим рабочим потоком, особенно в сценарии, в котором вы хотите динамически развертывать новую службу и вам нужно добавить навигацию к этой службе. Могут также существовать другие проблемы с перекрестными разрезами, такие как услуги, которые охватывают другие сервисы. Благодаря, Деклан.