Модульные веб-приложения
https://stackoverflow.com/questions/126073
-
02-07-2019 - |
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
RussianВопрос
Я тут изучал OSGi недавно я подумал, что это выглядит действительно хорошей идеей для модульных Java-приложений.
Однако мне было интересно, как OSGi будет работать в веб-приложении, где вам нужно беспокоиться не только о коде, но и о HTML, изображениях, CSS и тому подобном.
На работе мы создаем приложение, которое имеет несколько "вкладок", каждая из которых является частью приложения.Я думаю, что это действительно могло бы принести пользу от использования подхода OSGi - однако я действительно не уверен, что было бы лучшим способом обрабатывать все обычные ресурсы веб-приложения.
Я не уверен, имеет ли это какое-либо значение, но мы используем JSF и Ледяные лица (что добавляет еще один уровень проблем, потому что у вас есть правила навигации, и вы должны указать все файлы конфигурации faces в вашем web.xml...дох!)
Редактировать:согласно этот поток, faces-config.xml файлы могут быть загружены из файлов JAR - так что на самом деле возможно включить несколько faces-config.xml файлов без внесения изменений web.xml при условии разделения на файлы JAR.
Будем очень признательны за любые предложения :-)
Решение
Вы совершенно правы, думая, что здесь есть синергия, у нас есть модульное веб-приложение, где само приложение собирается автоматически из независимых компонентов (пакетов 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 на основе центральной сетки сайтов, который определяет глобальную компоновку сайта, а также центральные библиотеки 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 и его превосходной компонентной модели, чтобы действительно обеспечить разработку компонентных веб-приложений.
Другие советы
Проверьте Сервер dm SpringSource - сервер приложений, полностью построенный в терминах OSGi и поддерживающий модульные веб-приложения.Он доступен в бесплатной версии с открытым исходным кодом и коммерческой.
Вы можете начать с развертывания стандартного файла WAR, а затем постепенно разбить свое приложение на модули OSGi, или "пакеты" на OSGi-speak.Как и следовало ожидать от SpringSource, сервер обладает отличной поддержкой Spring Framework и связанных с ним продуктов Spring portfolio.
Отказ от ответственности:Я работаю над этим продуктом.
Будьте в курсе работы сервера Spring DM лицензирование.
Мы использовали Рестлет с OSGi хороший эффект достигается благодаря встроенному Http-сервису (на самом деле это Jetty, но tomcat тоже доступен).
Restlet имеет нулевые или минимальные потребности в настройке XML, и любая конфигурация, которую мы выполняем, находится в BundleActivator (регистрация новых сервисов).
При создании страницы мы просто обрабатываем соответствующие реализации сервиса для создания выходных данных в стиле декоратора.Новые подключаемые пакеты добавят новые украшения страницы / виджеты при следующем ее рендеринге.
REST предоставляет нам красивые, чистые и осмысленные URL-адреса, множественные представления одних и тех же данных и кажется расширяемой метафорой (несколько глаголов, много существительных).
Бонусной функцией для нас стала обширная поддержка кэширования, в частности ETag.
SpringSource, похоже, работает над интересным модульным веб-фреймворком, построенным поверх OSGi, который называется Фрагменты SpringSource.Более подробную информацию можно найти в следующих сообщениях в блоге:
Взгляните на РЭП! http://www.eclipse.org/rap/
Взгляните на http://www.ztemplates.org который прост и легок в освоении.Это позволяет вам поместить все связанные шаблоны, javascript и css в один jar и использовать его прозрачно.Означает, что вам даже не нужно заботиться об объявлении необходимого javascript на вашей странице при использовании предоставленного компонента, поскольку фреймворк делает это за вас.
Интересный набор постов.У меня есть веб-приложение, которое настраивается индивидуально для каждого клиента.Каждый клиент получает базовый набор компонентов и дополнительных в зависимости от того, на что он подписался.Для каждого выпуска мы должны "собрать" правильный набор сервисов и применить правильную конфигурацию меню (мы используем struts menu) в зависимости от клиента, что, мягко говоря, утомительно.В основном это та же кодовая база, но мы просто настраиваем навигацию, чтобы показывать или скрывать определенные страницы.Очевидно, что это не идеально, и мы хотели бы использовать OSGi для компонентизации сервисов.Хотя я вижу, как это делается для API-интерфейсов сервисов, и вроде как понимаю, как такие ресурсы, как CSS, java script и контроллеры (мы используем Spring MVC), также могут быть объединены, как бы вы справились с "сквозными" проблемами, такими как навигация по страницам и общий рабочий процесс, особенно в сценарии, когда вы хотите динамически развернуть новую службу и вам нужно добавить навигацию к этой службе.Могут также существовать другие "сквозные" проблемы, такие как услуги, которые охватывают другие виды услуг.Спасибо, Деклан.
