Как разделить корпоративное приложение на модули с помощью OSGi и EE6?
Я знаю, что уже есть некоторые вопросы, связанные с этой темой, но я пока не нашел реального решения.
В настоящее время я разрабатываю приложения с EE6, используя JPA, CDI, JSF. Я хотел бы использовать более модульный подход, чем упаковать все в WAR или EAR и развернуть все это на сервере приложений.
Я пытаюсь проектировать свои приложения как можно более модульными, разделяя модуль на 3 проекта maven:
- API -Содержит интерфейсы для (служб без сохранения состояния )
- . Модель -Содержит объекты JPA для конкретного модуля
- . Impl -Содержит реализацию API, в основном компоненты CDI
. Логика просмотра каждого модуля в настоящее время объединена в большой веб-проект, что выглядит некрасиво. Я уже думал о веб-фрагметах, но если бы я распространял свои классы bean-компонентов и файлы xhtml в файлы jar, мне пришлось бы реализовать хук, чтобы родительское веб-приложение могло искать ресурсы. Такое решение, по крайней мере, позволило бы мне иметь четвертый проект для каждого модуля, который содержал бы всю логику представления, связанную с модулем, что является хорошим началом.
Я хочу не только того, чтобы у меня были эти 4 типа проектов, но и того, чтобы каждый проект можно было заменять в горячем режиме. Это привело меня к OSGi, который поначалу был действительно крут, пока я не понял, что технологии EE6 не очень хорошо поддерживаются в контейнере OSGi.
JPA
Давайте сначала посмотрим на JPA. Существует несколько руководств[1], в которых объясняется, как создать пакет OSGi с поддержкой JPA, но ни в одном из этих руководств не показано, как распределять объекты по разным пакетам (модельному проекту модуля ).Я хотел бы иметь, например, три разных модуля
- Ядро
- Пользователь
- Блог
Типовой проект модуля блога имеет (зависимость -времени компиляции )от модельного проекта пользователя. Модельный проект пользовательского модуля имеет зависимость (времени компиляции -)от модельного проекта ядра.
Как я могу заставить JPA работать в таком сценарии, не создавая Persistence Unit для каждого модельного проекта модуля? Мне нужен один блок сохраняемости, который знает обо всех объектах, доступных во время выполнения. Разумеется, модельные проекты, в которых находятся сущности, должны поддерживать горячую замену. Возможно, мне нужно будет сделать отдельный проект для каждого клиента, который импортирует все необходимые объекты проектов и содержит файл persistence.xml, который включает все необходимые настройки. Существуют ли какие-либо доступные плагины maven для создания таких проектов или даже другие подходы к решению этой проблемы?
ЦДИ
ЦДИ очень хорош. Я действительно люблю это, и я не хочу пропустить это больше! Я использую расширения CDI, такие как MyFaces CODI и DeltaSpike, которые просто потрясающие! Я внедряю свои (службы без сохранения состояния )в другие службы или на уровень представления, и это просто здорово. Поскольку мои службы не имеют состояния, их использование в качестве служб OSGi не должно быть проблемой, но как насчет интеграции CDI в OSGi? Я нашел расширение Glassfish CDI Extension [2], которое будет внедрять службы OSGi в компоненты CDI, но я также хочу, чтобы службы OSGi были компонентами CDI. Я не совсем уверен, как этого добиться, возможно, мне придется использовать BeanManager для создания экземпляров реализаций, а затем регистрировать каждую реализацию для своего интерфейса в ServiceRegistry в BundleActivator. Есть ли какой-нибудь стандартный способ сделать это? Я хотел бы избежать каких-либо (компиляций -времени )зависимостей от фреймворка OSGi.
Я также хотел бы использовать свои услуги так же, как я использую их прямо сейчас,без каких-либо изменений (реализации не аннотированы и точки внедрения не определены ). Существует расширение/подпроект JBoss Weld[3], который, по-видимому, нацелен на эту проблему, но, похоже, он неактивен, я не могу найти какие-либо рекомендации или способы -tos. Как я могу оставить свою реализацию как есть, но при этом иметь возможность использовать OSGi? Я имею в виду, что было бы несложно добавить аннотацию к реализациям, поскольку каждая реализация уже снабжена аннотацией стереотипа, в любом случае я хотел бы предотвратить это.
JSF
Как упоминалось ранее, я хотел бы иметь возможность распространять свой логический модуль представления. Насколько я знаю, это невозможно из коробки. Pax Web[4] должен каким-то образом решить эту проблему, но я с ней не знаком.
Я хотел бы иметь проект «CoreWeb» в модуле «core», который содержит шаблон Facelet, назовем его «template.xhtml». Страница JSF в проекте под названием «BlogWeb» в модуле «блог» должна иметь возможность ссылаться на этот шаблон и применять композицию.
Чтобы иметь возможность расширить представление, я бы представил java-интерфейс «Расширение», которое может быть реализовано с помощью определенного класса модуля. Затем контроллер для представления будет внедрять все реализации расширения. Расширение, например, предоставит список подвидов, которые будут включены в основной вид.
Описанный механизм расширения можно легко реализовать, но должны быть выполнены следующие требования:
- При добавлении новых пакетов OSGi на сервер приложений набор доступных расширений может измениться, расширения должны быть доступны для контроллера представления.
- Должны быть доступны подвиды (из отдельного пакета ), которые должны быть включены в основной вид.
Концепция одного хоста, но нескольких приложений слайсов Spring Slices[5] очень интересна, но кажется ограниченной Spring DM Server, и проект также кажется неактивным.
Резюме
Надеюсь, после всех описанных мной примеров и моделей поведения вы знаете, чего я хочу добиться. Это просто приложение EE6, очень динамичное и модульное.
В конце я ищу, по крайней мере, документацию о том, как заставить все работать так, как я ожидал, или, что еще лучше, уже работающее решение!
[1] http://jaxenter.com/tutorial-using-jpa-in-an-osgi-environment-36661.html
[2] https://blogs.oracle.com/sivakumart/entry/typesafe_injection_of_dynamic_osgi
[3] http://www.slideshare.net/TrevorReznik/weldosgi-injecting-easiness-in-osgi