Кто-нибудь развернул корпоративное приложение в OSGi и нашел его полезным?
Я вижу преимущества, принудительную модульность, хорошие определения зависимостей и т.д. Но они, похоже, в основном связаны с улучшением сборки.
Кто-нибудь нашел полезным динамически заменять существующий модуль? Мы стремимся разделить наше приложение на процесс и, честно говоря, не так сложно запустить новый экземпляр приложения с обновленными библиотеками. Будет ли OSGi полезен для этого?
Насколько надежна замена модуля? Мне кажется, что если у вас очень напряженный процесс, когда происходит много, замена работающего модуля чревата опасностью.
Я только что писал о том, почему мы не пошли с OSGi
В двух словах, я считаю, что основы OSGi прочны, но не были созданы для массового применения. Он вводит трения в процесс разработки/развертывания, который уже чреват проблемами. Я бы хотел, чтобы спецификация OSGi больше ориентировалась на личность разработчика/пользователя OSGi, чтобы сделать ее невидимой для процесса разработки. Также я потрясен тем, что JVM до сих пор не имеет прозрачного стандарта модуля.
Большинство наших приложений - это веб-приложения.
У нас есть один клиент OSGi толщиной, который собирает биометрическую информацию. Фотографии и отпечатки пальцев через сканирование отпечатков пальцев, в настоящее время.
Преимущество OSGi в том, что мы можем обновлять плагины с центрального веб-сайта, а не использовать процесс удаления/установки. Наш толстый клиент будет в более чем 100 местах по всей территории Соединенных Штатов, поэтому это было важно для нас.
Я работаю в телекоммуникационной среде. Что-то вроде OSGi будет очень полезно для нас. Мы развертываем приложения для клиентов, которые не могут выйти в автономный режим, не получая прибыль. Они обрабатывают тысячи вызовов в секунду. Прямо сейчас, они должны делать обновления в своем окне обслуживания, чтобы принимать новые исправления или обновления.
Если мы сможем доставлять исправления и улучшения как горячее развертывание, это будет иметь большое преимущество. Но, конечно, перед тем, как мы это сделаем, есть фактор риска и дополнительные усилия по тестированию с помощью имитированного теста трафика.
OSGi предназначен не только для динамических обновлений, он хорош для таких вещей, как управление версиями, чтобы убедиться, что правильная версия выбрана в сложной среде.
Мы начинаем изучать OSGi, я буду публиковать обновления, если найду что-нибудь интереснее.
Мы используем его в большой телекоммуникационной компании. Мы имеем его в производстве в течение 2 лет, и мы продолжаем добавлять пакеты теперь у нас около 110 пакетов.
Ребята из команды в восторге от тонкого контроля, который им дают: они могут начать останавливать отдельные функции и контролировать их. Теоретически мы могли бы также hotdeploy новую версию в производстве, но в реальности мы используем эту функцию только при выполнении теста и preprod.
Наша широкая архитектура кисти основана на следующем: http://servicemix.apache.org/home.html
Наша основная проблема - всегда пытаться использовать стандартную java-инфраструктуру в osgi. Вторая проблема - это управление импортом/экспортом пакетов. Мы используем плагин maven.
В целом мы довольны этим выбором, но вам нужно рассмотреть 2 вещи: 1. Вы готовы сражаться с любой рамкой java, которую хотите добавить? 2. Вы достаточно дисциплинированы, чтобы не испортить свою зависимость?