Приветствую!

Сейчас разбираюсь с OSGi. Возникает вопрос - а есть ли смысл в использовании этого framework при создании desktop клиента корпоративного приложения? Судя по описанию - одни из главных фишек - это динамически загружаемые/выгружаемые модули. Для enterprise сервера, в работе которого важен uptime смысл использования OSGi понятен. Но в клиенте это видимо не будет востребовано? Также одна из целей использования возможности выгрузить модуль по историческим причинам (т.к. изначально OSGi разрабатывалась для мобильных платформ) была оптимизация по использованию памяти. Для обычного desktop приложения это тоже не особо актуально.
Остается вопрос - использование OSGi для сервера (например Glassfish) оправдано, то есть ли смысл в его использовании в обычном desktop клиенте? Или достаточно реализации модульности с использованием обычного maven и Spring ?

Первое, что пришло на ум - Eclipse, с версии 3.x построенный на OSGi. Фишки - плагины, быстрая смена/апгрейд и т.д. Минусов с точки зрения работы не замечал.

P.S. По идее, тему скоро переместят в Java IDEs...   

Не понятно как именно в Eclipse IDE используются преимущества OSGi. Весь этот динамизм загрузки/выгрузки в процессе работы самой среды разработки как используется?

Вообще тоже стало интересно, решил "полазить", посмотреть.

Многое сводится к тому, что OSGi позволяет динамически добавлять/убавлять/модифицировать функционал в уже работающем приложении. По личному опыту скажу, что приложение допустим на Apache Felix достаточно легко в последствии обвешать новыми фичами. 
Spring(а также Google Guice из недавнего) как Dependency Injection Framework модульный, но по сути своей статичен - то есть bean и bean_consumer связываются в самом начале и так и остаются связанными до конца работы приложения. То есть запатчить клиента "на лету" без остановки приложения не получится. Вопрос, надо ли это desktop приложению? (почему бы и нет, если это биржевой клиент, где секунды могут быть на счету)

Похоже на то, что Spring дает модульность в рамках приложения, тогда как OSGi позволяет более серьезную модуляцию, где каждый модуль может быть отдельным приложением, что, согласен, делает его больше подходящим как раз для серверных приложений. Хотя в Eclipse тоже неплохо смотрится.

Кстати.
Сейчас с версии 4.2 (вроде) в OSGi добавлен Spring Dynamic Modules, где вроде как объединены преимущества обоих.

Согласен. Сейчас создал небольшой пилот с использованием Felix. Все замечательно работает. Динамически грузятся/выгружаются плагины, ядро всем этим управляет... Но у нас большое клиентское приложение ( desktop, swing, javaee-cleint... ) запускается с помощью Java Web Start. Т.е. каждый раз по щелчку на гиперcсылке запускается клиент, который потом сам подключается к серверу (Glassfish). Таким образом динамизм загрузки/выгрузки плагинов в данном случае не нужен, т.к. по факту все модули, которые необходимы для работы грузятся на startup-time. И выгружать их нет никакой необходимости, т.к. обновления плагинов происходят централизованно на сервер в виде нового ear файла. И при следующем клике на ссылке загрузится новый клиент и новые версии плагинов. Делаю вывод - в нашем случае нет смысла в реализации динамических модулей. Но остается еще один большой плюс - отдельный class loaders для каждого bundle... Вопрос - стоит ли овчина выделки, если от OSGi взять только эту фичу, а динамическим обновлением модулей пренебречь?

Преимушества, наверное, не только в том, что буквально "на лету" (и при перезапуске приложения бывает вполне достаточно)  , а и в том, что энтузиасты всего мира пишут плагины, расширяющие возможности ИДЕ (а другие энтузиасты их пробуют),  и контейнер осуществляет контроль соответствия интерфейсов, версий. Он не подключит то, что не соответствует стандарту. 

В корпоративном приложение тоже возможно, что разработка компонентов отдана на сторону (или просто в соседнюю комнату) и наличие автоматического контроль соответствия "разьемов" стимулирует и облегчает такой подход.



Как раз острая необходимость использования OSGi для сервера мне не совсем очевидна. Томкат (и другие) и до OSGi умел "на лету" деплоить веб-приложения. Не надо строить "монстров" и не будет проблем с быстрым перезапуском и др. На серверной стороне есть широкие возможности. А вот для клиентов, как мне представляется, OSGi актуальнее. Клиенты разнообразнее и динамичнее, потому что разные группы пользователей могут хотеть разный набор (меняющийся) функциональностей, клиенты работают в разных условиях и могут быть разнесены географически. 



Насколько я понимаю это означает "пересборку" , т.е. фактически создание нового приложения, доставку его пользователю и инсталляцию. А OSGi дает возможность пользователю (который не программист) нажать кнопку в меню приложения, выбрать из списка доступный модуль (покоящийся на удаленном сервере) и инсталлировать его (пусть даже и с перезапуском приложения).




Я тоже играл с Felix + Web Start (но не закончил). Обновление приложения так же, как и у вас, происходит в момент запуска приложения. Тут есть нюанс. Web Start приложение обычно состоит из набора jar-ов. Если один из них изменился, то Web Start перезагрузит только эту библиотеку. Это ценно, потому что уменьшает время старта. 

Если же использовать OSGi, то реализовывать избирательное обновление библиотек приходится через функциональность репозитория бандлов контейнера (OBR),  т.e.  Web Start запускает только сам контейнер, а загрузка модулей управляется уже контейнером. Пришлось повозиться.



не совсем понятно, поясните, пожалуйста

Это сообщение отредактировал(а) COVD - 20.7.2010, 19:17

плагинную систему (в которой плагины загружаются только на startup-time, т.е. без возможности выключения/обновления "на лету") можно собрать как минимум двумя способами Spring или ServiceLoader. И тот и другой способ позволяет определить некий интерфейс Plugin который будут имплементить плагины и они будут динамически грузиться на старте приложения. Т.е. если мы каждую плагину оформим в виде отдельного jar и добавим его в classpath, то ядро их подхватит и загрузит. Spring в этом плане поудобнее будет - достаточно объявить @Autowired коллекцию. Штатное средство JDK - ServiceLoader тоже предоставляет такую возможность динамической загрузки плагинов, но в реализации чуток посложнее будет ( там надо спец файлы в META-INF создать и вручную пробежать по всем сервисам, которые выдаст ServiceLoader...

А насчет classloder'ов - судя по спецификации OSGi, следует, что каждый bundle загружается OSGi framework'om в отдельном classloader'e. Т.е. имеется возможность например написать одну плагину, которая зависит от Oracle JDBC 10 версии, а вторую плагину от Oracle JDBC 11 версии. Что при загрузке одним обычным classloader'om невозможно, т.к. подхватиться jar с драйвером, который будет первым в classpath.

А почему вы стали пробовать Web Start  + OSGi , а не Web Start  + Spring или Web Start  + ServiceLoader, если загрузка только на старте устраивает? 



Значит ваш вопрос (про "овчинку") можно переформулировать как имеет ли смысл взять из OSGi механизм контроля версий, а обновления "на лету" отбросить? Чтобы уменьшить размер контейнера плагинов?

у нас есть достаточно объемное desktop приложение. Оно реализовано в виде одного большого jar, что не есть хорошо. Планируется написание нового даже не major обновления, а формирование новой версии платформы. Приложение само по себе является enterprise (т.е. javaee сервер, desktop клиент + несколько web клиентов, взаимодействие через ejb, jms и lcds ). Я сейчас анализирую подходы/технологии для построения desktop клиента. Необходимо построить разработку приложения так, чтобы оно было модульным (слабо связанные модули) и часть из этих модулей должны быть плагинами, т.е. подгружаться в runtime (или startup time, т.к. особого смысла в подгрузке/обновлении плагин в runtime не вижу). В связи с этим мой интерес связан с OSGi. Но как я писал основная фишка OSGi в нашем случае не must have. Но помимо возможности с помощью OSGi динамически обновлять модули, сами эти модули в OSGi framework'e грузятся в отдельных classloader'ax. Что само по себе достаточно интересно ( как я писал ранее возможность загрузки двух модулей, которые классическим способом не загрузить). Вот и интересно ваше мнение - если мне не нужна фишка №1, но потенциально интересно использование фишки №2, то стоит ли копать дальше спецификации OSGi ( которые не особо простые и понятные )? Размер контейнера роли не играет.

Это сообщение отредактировал(а) sergey_nelyubin - 23.7.2010, 13:57

Мы тоже начинали с одного jar'a, но сейчас уже веб-старт клиент состоит из нескольких десятков. Это сделано для  уменьшения времени старта - когда меняетса один jar, то и перезагружается только он. По этой же причине мы меняем модифицированный jar на сервер вручную, т.е. не заменяем целиком war. Однако разделение клиентского приложения на библиотеки (или компоненты) сделано вручную. Приложение развивается, растет в размерах и пришло понимание, что надо формализовать процесс добавления новых компонент. Это задача перевода веб-старт приложения на модульную архитектуру. Я стал интересоваться Спринг, OSGi , Нетбинс-платформ. Сейчас я представляю, как это делать на OSGi - ключевой момент тут OBR. 


Я никак не пойму ваших сомнений относительно "фишек". Казалось бы, используйте то, что вам нужно и в чем разбираетесь. А что не нужно, не используйте.  Да. "Копать" стоит.

Это сообщение отредактировал(а) COVD - 23.7.2010, 17:00