OSGi — это новая платформа Java, а также надежное архитектурное решение, позволяющее избежать печально известного черта Jar во время разработки приложений Java.
Веб-интерфейсы — это еще одна довольно важная функция на сегодняшний день, и, насколько мне известно, в OSGi отсутствует собственное решение для реализации веб-приложений внутри пакетов (как это происходит со спецификацией ConfigurationAdmin, которую реализуют многие платформы OSGi).
Представляется разумным, что платформы OSGi могут использовать преимущества существующих, хорошо работающих решений, таких как контейнеры сервлетов, и интегрироваться в архитектуру веб-приложений, реализованных с сервлетами, файлами JSP и WAR.
Тем не менее, интеграция с сервлет-контейнерами является довольно экспериментальной в среде OSGi (хотя я надеюсь, что некоторые читатели меня опровергнут), и по сути есть два способа добиться того же: обслуживать HTTP-запросы из пакета OSGi.
Встраивать каркас OSGi в контейнер сервлетов
Equinox — это платформа OSGi с открытым исходным кодом, предоставляемая Eclipse Foundation. Equinox предоставляет веб-приложение Bridge.war, которое можно использовать для связи между Tomcat (как пример популярного контейнера сервлетов) и самим Equinox, предоставляя функции, необходимые для встраивания инфраструктуры в веб-приложение и туннелирования запросов к нему.
Уже есть очень хорошая статья, объясняющая механизмы этого типа интеграции, поэтому я не буду обсуждать это здесь. Тем не менее, я рассматриваю веб-приложения OSGi только в качестве внешнего интерфейса для всех приложений, состоящих из целого набора пакетов — если бы я хотел встроить весь свой код в веб-приложение, я бы выбрал платформу PHP. Ключевым преимуществом Java является его естественная способность работать асинхронно из запросов HTTP.
Я объясню другое решение, которое применяется средой Eclipse SMILA для поисковых приложений, построенной на основе OSGi.
Встраивать контейнер сервлетов в каркас OSGi
Давайте представим, что у вас есть приложение OSGi, возможно, с различными интерфейсами, которое запускает некоторые процессы в ответ на внешние события из любого вида пользовательского интерфейса — локального или удаленного. Было бы неплохо добавить веб-интерфейс к этому приложению, чтобы легко обрабатывать сценарии удаленного использования и оставлять приложение работающим в качестве основного потока в JVM.
Это именно подход SMILA . SMILA индексирует записи асинхронно, например, запуская сканеры на веб-сайтах или в дисковых папках. Пользовательский веб-интерфейс — это простое средство для поиска, но приложения SMILA не зависят от него.
В SMILA Jar-файлы Tomcat (и Catalina) встроены в один пакет org.apache.tomcat, который помещает их в Bundle-ClassPath и экспортирует различные содержащиеся в нем Java-пакеты, такие как org.apache.tomcat.util.
Другой пакет отвечает за упаковку функциональных возможностей Tomcat с Facade, который запускается как сервис OSGi. В случае SMILA этот пакет представляет собой org.eclipse.smila.tomcat и содержит класс TomcatServiceImpl, который активирует () и деактивирует () метод для управления жизненным циклом инфраструктуры Tomcat. TomcatService — это интерфейс, созданный SMILA, а не специфичный для Tomcat код, поэтому вы можете свободно включать Tomcat в свои реализации так, как считаете нужным.
Точка соединения между сервлетами и сервисами OSGi имеет решающее значение в этой настройке. Пакеты раскрывают свои функциональные возможности через сервисы, чьи жизненные циклы и разрешение зависимостей управляются платформой OSGi. С другой стороны, сервлеты должны удовлетворять HTTP-запросам и им нужен способ доступа к сервисам, которые представляют модель веб-приложения, используемого в качестве внешнего интерфейса.
Это соединение обеспечивается классом Activator, локальным для пакета сервлетов, независимо от двух пакетов, упомянутых ранее (и перечисленных в манифесте с заголовком Bundle-Activator). Этот активатор создает ServiceTracker для пакетов, необходимых его сервлетам, и предоставляет статические методы получения, которые сервлеты могут использовать для получения ссылки на службу. Нет никакой гарантии, что сервисы будут доступны, если вы не запустите их через их конфигурацию OSGi, но разрыв легко ликвидируется.
Настраиваемые папки для Tomcat (например, webapps / one) определяются службой OSGi, которая действует как Фасад, и я приглашаю вас обратиться к исходному коду SMILA, указанному в конце этой статьи, если вы хотите получить дополнительную информацию , Однако важной частью настройки является размещение папки, подобной WAR, для представления веб-приложения в выбранной папке webapps /. Вам строго не понадобится файл в этой папке, кроме WEB-INF / web.xml, который будет содержать сопоставления сервлетов с их полностью определенным именем (как стандарт проповедует).
Последнее важное замечание — убедиться, что пакеты, содержащие Jar-файлы Tomcat и их оболочки, могут видеть пакеты сервлетов, экспортированные другим пакетом. Самый простой способ добиться этого — использовать заголовки манифеста, специфичные для Equinox, которые сообщают загрузчику классов пакета Tomcat о необходимости требовать классов и другим конкретным пакетам. Эти заголовки
Eclipse-BuddyPolicy: registered
в связках Tomcat и Facade, и
Eclipse-RegisterBuddy: org.apache.tomcat, org.eclipse.smila.tomcat
в пакетах сервлетов (не забудьте также экспортировать пакеты, содержащие их). Вот как работают эти заголовки .
Последнее замечание: поддержка JSP гораздо сложнее настроить, и в настоящее время у меня не было времени на ее изучение. При таком простом переносе они не будут выполняться, поскольку сгенерированный код не сможет разрешить его зависимости. Если вы нашли какое-либо простое решение для интеграции также JSP в приложение OSGi, не стесняйтесь добавлять свои мысли в комментарии.