Я сделал это два года назад: OSGi и GWT, чтобы не было простоев развертывания модулей проекта.
Вердикт: не делайте этого, если вам действительно не нужно.
Короче говоря, OSGi - зверь, и модернизация существующего приложения для него далеко не тривиальна . Вы больше не создаете файлы .war (.ear сейчас) и не можете использовать стандартные jars и репозитории Maven, которые вы использовали ранее. Теперь все должно быть в комплекте. Проблема в том, что многие вещи (GWT, Spring, тонны библиотек) не являются связками! И вам нужно будет найти их в репозитории корпоративных пакетов или, что еще интереснее, начать самостоятельно перебирать сторонние источники. Еще лучше сказать другим разработчикам переписать все, что использует их любимую библиотеку, потому что связывание было бы слишком сложным.
Партия GWT не заняла так много работы . То, как контексты для модулей обрабатывались в gwt-servlet, пришлось изменить, чтобы каждый модуль мог найти свой контекст на сервере. Нам также пришлось предоставить большинству служб GWT возможность регистрироваться / отменять регистрацию при загрузке и службу обнаружения, чтобы они могли знать, кто еще там был.
Теперь другая боль: проектный взрыв .
Допустим, у вас было 20 модулей, которые вы хотели развернуть независимо. Ну, во-первых, они, вероятно, более связаны, чем вы хотели бы, поэтому лучше потратить несколько недель, разбивая их на независимые проекты Maven и добавляя общие части в проект lib. Но теперь у вас есть куча зависимостей, которые нужно отслеживать. Когда кто-то настраивает ваш проект lib, вам нужно обновить каждый проект или только 7 из них? В классическом остановке мирового развертывания у вас была только одна версия всего вашего кода. Теперь вам нужно решить, потребует ли эта обновленная форма забытого пароля обновлять модуль страницы индекса. У вас будет тонна номеров версий, чтобы составить и отслеживать. В нашем случае на нашем CI-сервере мы все время строили 55 проектов Maven. Это означало, что некоторые проверки могут вызвать 55 сборок. Ик.
Наконец, JSON-интерфейсы .
Мы использовали GWT RPC. Это волшебно. Напишите интерфейс и все просто работает. Он также сериализован и разархивирован по проводам. Потрясающие. Но политики сериализации зависят от таблиц поиска объектов и строк, которые создаются во время компиляции для каждого модуля. Таким образом, проект A не может RPC для проекта B. Boo. Мы решили использовать JSON из-за постепенной деградации, которая не перестает работать, когда в объектах присутствуют новые нераспознанные свойства. Это означает, что вам снова понадобится способ сохранить все вызовы бэкэнд-сервиса согласованными с версиями JSON, которые они ожидают и могут обрабатывать. Лучше смоделируйте это живое обновление также заранее.
Итак, последнее слово: возможно, но почему? Нужно ли вам OSGi для горячего развертывания модулей , потому что вы работаете с критически важным для бизнеса приложением, работающим на 1000%? Или ваш босс / архитектор просто отказывается признать, что 99,999% - это достаточно хорошо? Вероятно, вам не нужно это время безотказной работы, и вы можете достичь почти 100% времени безотказной работы с хорошим прокси-сервером, чтобы вы могли получать экземпляры в / из пула балансировщика. Кроме того, не забывайте, что даже если вы можете обновить свои проекты в прямом эфире, я надеюсь, у вас есть способ обновить базу данных на лету, не прерывая ни одной транзакции.