Миграция с монолитного приложения Spring на OSGI

Я предлагаю вам взглянуть на blueprint-maven-plugin. Это позволяет использовать подмножество аннотаций CDI и JEE для определения инъекций, а также транзакций и постоянства. Плагин создает xml чертежа во время сборки, который затем может быть выполнен karaf. Большим преимуществом является то, что эти аннотации также поддерживаются Spring. Таким образом, вы можете переходить и параллельно выпускать в производство, используя spring.

У меня есть полный пример здесь план на основе аннотаций и JPA.

С помощью этого плагина я перенес проект среднего размера, пока он разрабатывался и выпускался параллельно. Если вам нужны дополнительные советы при использовании плагина, я, безусловно, могу помочь.

Вы можете подумать о том, чтобы сделать проблему выглядящей еще более серьезной и переключиться на DS вместо Blueprint... Чтобы по-настоящему воспользоваться преимуществами модели OSGi, DS намного превосходит Blueprint во всех аспектах. На самом деле, после первого препятствия вы добьетесь гораздо большего прогресса, и ваши успехи будут выше. Хотя Blueprint сделал Spring доступным для OSGi, он так и не «получил» OSGi.

Для стратегии держите свое приложение Spring в виде единого пакета и постепенно удаляйте его. т.е. слоновий подход.

Самый большой выигрыш, который дает OSGi, можно резюмировать следующим образом:

• Убедитесь, что в модулях есть сервисные API, которые ТОЛЬКО обрабатывают совместную работу. т.е. API каждого сервиса должен быть историей/сценарием того, как действующие лица работают вместе, а не тем, как они возникают и настраиваются.
• Позвольте администратору конфигурации работать с конфигурацией. т.е. никогда не раскрывайте API конфигурации. В OSGi вы регистрируете экземпляры, а не то, что еще нужно настроить.

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