Переход с монолитного приложения Spring на OSGI
За последние 10 лет мы создавали два пакета приложений, используя Spring в качестве инъекции зависимостей. Мы также используем spring-batch и spring-amqp. Сейчас мы ожидаем перехода на OSGI, чтобы наши монолитные приложения можно было разделить на пакеты, чтобы мы могли быть более гибкими. Эти два набора являются веб-приложениями и развернуты в виде двух отдельных военных файлов. Мы надеемся использовать Apache Karaf в качестве среды выполнения OSGI.
Spring-DM мертв, и, похоже, нам придется конвертировать ВСЕ, чтобы использовать Blueprint для внедрения зависимостей.
Мой вопрос, как мы делаем это постепенно? Будет почти невозможно преобразовать все это сразу. Кажется, что один пакет должен все еще иметь возможность использовать Spring DI и иметь собственный контекст приложения, если мы берем на себя ответственность выставлять любые сервисы, которые мы хотим, в реестр сервисов в активаторе пакета, но я не уверен, есть ли это какая-то магия, которую мы потеряли бы, как управление транзакциями.
Любое руководство по этому вопросу будет оценено.
2 ответа
Я предлагаю вам взглянуть на blueprint-maven-plugin. Это позволяет использовать подмножество аннотаций CDI и JEE для определения инъекций, а также транзакций и персистентности. Плагин создает blueprint xml во время сборки, который затем может быть выполнен karaf. Большим преимуществом является то, что эти аннотации также поддерживаются весной. Таким образом, вы можете переходить и параллельно выпускать в производство с помощью пружины.
У меня есть полный пример здесь аннотации на основе проекта и JPA.
Используя этот плагин, я перенес проект среднего размера, пока он разрабатывался и выпускался параллельно. Если вам нужен дополнительный совет при использовании плагина, я, безусловно, могу помочь.
Возможно, вы захотите сделать проблему еще более масштабной и переключиться на DS вместо Blueprint ... Чтобы по-настоящему воспользоваться моделью OSGi, DS намного превосходит Blueprint во всех аспектах. На самом деле, после первого препятствия вы добьетесь гораздо большего прогресса, и ваши выгоды будут выше. Хотя Blueprint сделал Spring доступным для OSGi, он так и не получил OSGi.
Для стратегии поддерживайте живое приложение Spring как единый пакет и постепенно перемещайте его. Т.е. слон приближается.
Самый большой выигрыш, который обеспечивает OSGi, можно суммировать следующим образом:
- Убедитесь, что модули имеют сервисные API, которые ТОЛЬКО обрабатывают совместную работу. Т.е. каждый API службы должен представлять собой историю / сценарий о том, как актеры работают вместе, а не о том, как они возникают и настраиваются.
- Пусть Конфигурация Admin для конфигурации работает. Т.е. никогда не выставлять API конфигурации. В OSGi вы регистрируете экземпляры, а не вещи, которые все еще необходимо настроить.
Убедитесь, что вы действительно понимаете модель OSGi с сервисами. Возможно, вы захотите взглянуть на OSGi enRoute, который использует OSGi на рукоятку.