Комментарии 51
Итак, допустим вы решили попробовать OSGI на платформе Karaf

А зачем уж я это решил в 2019 году, напомните мне? :)


В век-то выстреливших микросервисов и такого прочего..

Там написано «допустим». Это вполне может означать, что вы и не решили. Не вижу в этом никаких проблем.

>В век-то выстреливших микросервисов
Вообще-то, karaf как раз и есть отличная среда для этих самых микросервисов. Которая обеспечивает им определенный уровень изоляции, с одной стороны, и в тоже время, определенный уровень централизованного управления, развертывания, мониторинга и прочего. Я вполне себе разворачивал проект, содержащий десятки своих бандлов, силами одного человека, то есть меня. И силами небольшой команды — шину на сотни сервисов.

То есть, говоря по-простому, имея под рукой karaf, мне вообще микросервисы как таковые и не нужны — потому что бандл это и есть микросервис. Ну, с некоторыми понятными ограничениями на платформу, т.е. все микросервисы будут под JVM, а не написаны на условном Go или питоне.

А если у вас скажем есть микросервисы, то вам все эти проблемы (управления, развертывания, мониторинга) так или иначе все равно придется решать. И для меня скажем далеко не факт, что будет лучше. У разных вариантов есть свои преимущества и недостатки.

>такого прочего.
Вот тут можно поподробнее, какого «такого прочего»?
Да и в самой JVM сейчас есть решение части задач OSGI в виде JPMS.
Вообще-то, их области применимости даже почти не пересекаются.

А какая область применимости OSGI и какая область применимости JPMS?

Реальная область применимости OSGI — это куча JavaEE и ESB, которые на нем основаны. А еще к примеру OpenHAB, то есть разного рода IoT и умные дома.

Можете себе представить разработку скажем ESB на основе JPMS? Т.е. контейнер, куда в runtime добавляются модули, запускаются, останавливаются, каждому из них нужны зависимости, которые тоже динамически устанавливаются и разрешаются (в случае карафа — например из maven репозитория). Я не вижу вообще, каким боком сюда JPMS.
Реальная область применимости OSGI — это куча JavaEE и ESB, которые на нем основаны.

А у JPMS какая?


Можете себе представить разработку скажем ESB на основе JPMS?

Вообще не очень, но может это из-за того, что я с JPMS толком не работал.

Ну, я для себя не нашел области применения JPMS, что впрочем не значит, что ее нет. Но она очевидно ближе к времени компиляции и сборки, т.е. направлена скорее на сборку кастомного приложения (в том числе JDK). То есть, на выходе мы получаем некий кастомный runtime+приложение.

Например маленький, что было бы неплохо для мобильных железок или embedded.

Очевидно, что к очень многим областям, которые покрывает OSGI (например, условный JNDI и вообще Java EE), и ко всей части DI (blueprint в том числе) это просто никакого отношения не имеет.
Очевидно, что к очень многим областям, которые покрывает OSGI, например, ко всей части DI, JPMS отношения не имеет.

Я тут подумал, получается, что имеет. Один из механизмов DI — java.util.ServiceLoader и он связан с модулями напрямую.

Ну как бы это маленькая часть всей картины. Дело в том, что скажем Pax-Web в контейнере работает так — он слушает контейнер, и ждет появления реализации интерфейса сервлета. И когда такая реализация деплоится, он ее сразу подключает, и сервлет начинает работать. Ну и где это все?
Связан, только нет динамизма в рантайме «из коробки». Все таки JPMS больше про модуляризацию JVM, чем про микросервисы и динамическую загрузку/выгрузку сервисов
У меня на проекте как раз микросервисная архитектура на базе jboss fuse(karaf) с хранением зависимостей фичеров в артифактори, компоненты системы на разных серваках, кластеризация и вот это все.
Есть правда неудобство с конфигурированием профилей, не очень удобно делать это через консоль. Веб морда лагучая, hawtio тож тормозит при работе через jms. Проблему решили написав и установив бандл на корневой инстанс, работающий с сервисами фьюза напрямую.
Ну, консоль — это все-таки для ручных работ. Автоматизация — это скорее либо JMX, либо ssh. Я делал и так и эдак, в целом оба варианта рабочие.
Ну, я из тестирования, в итоге мы наружу ресты вывели бандлом и радуемся :)
Я даже rest не стал выводить, хотя сначала тоже думал: jolokia, туда-сюда :)

Но поскольку все бандлы уже есть в JMX в виде MBeans, а JMX доступен по сети небольшими усилиями (ну, скажем, чтобы совсем кто попало не лазал, нужно кое-какую авторизацию и ролевую модель), то дальше берем groovy в руки, GroovyMbean, и за 15 минут прикрутил внешний мониторинг, например, с выходом на Nagios.
Кстати, вопрос: а почему вы думаете, что микросервисы выстрелили?

Вот пример мнения от 2016 года, тогда это не выглядело как свершившийся триумф, и мое мнение тогда практически совпадало с мнением автора.

Понятно что условные докер или kubernetes развивались, не стояли на месте. Что-то изменилось принципиально? Какие-то из описанных тогда проблем кардинально решены?
я лучше отвечу, почему osgi не выстрелил. он остался нишевым продуктом.

что-то кроме карафа, эквинокса? spring dm примкнувший к эклипс фаундейшн там и почил, например.

технология не популяризуется, не обрастает удобствами в отличие от микросервисов.
я тыкал osgi, когда оно было только в эквиноксе, когда спрингсорс это начинание подхватил, но потом почему-то в стороночку отложил и аккуратненько забыл. Я наблюдал со стороны за этим и не видел достаточно стабильно нарастающей популярности данной технологии.
>что-то кроме карафа, эквинокса?
Полно. Умный дом, к примеру. На совсем мелких железках.

>spring dm примкнувший к эклипс фаундейшн там и почил, например.
Во-первых, вместо него Blueprint, вы просто пост не очень внимательно прочитали.

А сам spring dm просто живет и здравствует, потому что его работоспособность не нарушилась, и он решает все задачи, какие должен — то есть, мы берем приложение на спринге, обычное, а не DM, деплоим в караф, и о чудо — оно работает! Добавляем чуточку DM, в виде пары таглибов, и оно уже понимает сервисы карафа, или публикует свои.

>аккуратненько забыл.
Об этом и речь, что многие думают как вы. Посмотрели на технологию 10 лет назад (да, она тогда уже была), и решили, что ничего не меняется. Однако менялось. С тех пор разрабатывать под OSGI стало просто и удобно. Месяц на вход. Потом двадцать интеграций разного рода за пару лет, на куче разных механизмов.

Нишевая технология? Ну, с тем же успехом можно считать, что и JavaEE сегодня нишевая. По сравнению с андроид, и его масштабами по числу установок приложений — просто небо и земля. Просто мало кто пишет свои ESB-шины.
spring dm исчез из портфеля спрингсорса просто так, например? я не говорю, что технология сдохла. энтерпрайз (конкретно сейчас, в лице спрингсорса) от неё отвернулся. есть повод задуматься…

про блюпринт, не переживайте, в курсе. ему уже лет десять как… блюпринту этому…
>spring dm исчез из портфеля спрингсорса просто так, например?
Gemini Blueprint является непосредственным развитием кода spring dm, и официально рекомендуется вместо него. Он не исчез — на его основе написали другой продукт, более современный. Но при этом старый код версии аж 1.2.1, все еще успешно работает. Spring DM конечно легаси, но он никуда не делся.

>про блюпринт, не переживайте, в курсе.
Вот не похоже, чтобы вы знали его историю.

Так что ваши выводы в части spring неверные, и непонятно на чем основаны.
Гражданин, пройдемте! Вот это список проектов, развиваемых, на данный момент, компанией спрингсорс (зачеркнуто) пивотал. Блюбёрд, гемини, принг дм? Ихтамнет!

А были. И ушли ровно тогда, когда они это всё отдали в эклипс. После этого проект живет на «энтузиастах опенсорса».

Своими комментариями я совершенно не пытаюсь предать osgi анафеме, сказать, что микросервисы — серебряная пуля, рулят и педалят и т.д.

Но на данный момент osgi — маргинальщина. За сим разрешите откланяться. Дальше я это усугублять не буду :)

P.S.: Кстати, как там r-osgi? не загнулся? :)
>энтерпрайз (конкретно сейчас, в лице спрингсорса) от неё отвернулся
Хм. Вот интересно, спрингсорс значит энтерпрайз, а я тогда кто? Мой проект был сделан по заказу FI Desk одного довольно крупного инвестиционного банка. Я и есть самый что ни на есть энтерпрайз, во всей его кровавости, разве нет? :)
> а я тогда кто?

до того, как начал размахивать — простой регистрант с хабра. а теперь надо nda перечитать на предмет разглашения названия конторы :-D
Не смешите. Я почти на все банки из первой десятки РФ поработал, никогда такого в NDA не было, нет, и не будет.
> энтерпрайз (конкретно сейчас, в лице спрингсорса) от неё отвернулся. есть повод задуматься…

Задумался в свое время. И пришел для себя к выводу, что произошло это потому — что всеми так разлюбимый спринг — один большой пучок рантайм-магии с кодогенерацией и рефлексией, а OSGi такие выкрутасы не любит. И вот ИМХО это — спринговый слив, а не OSGiшный.
надо просто у, хотя бы, одного энтерпрайза osgi в портфеле найти… Тогда можно будет начать менять это мнение :)

ESB — есть, микросервисы — есть. А вот osgi я что-то ни у кого не видел в портфеле.
Ну вот он я. Причем заметьте — ESB у меня была два раза, один раз — в виде Websphere, а второй уже караф, camel и всякие разные вариации типа Fuse. И что я могу про это сказать — что второй вариант значительно, нет ЗНАЧИТЕЛЬНО удобнее в работе. Ну то есть, я за три с половиной года примерно ни разу не пожалел о выборе именно этих технологий.
То что OSGi и тот же Karaf/ServiceMix — основа кучи EE-шных же контейнеров и ESB-шных же шин — не считается?
И еще, на минуточку, на OSGI работает Nexus. А значит (вероятно) и maven central. В прочем, это не точно.
Да дело не в этом даже. Берем свежий караф. Берем spring-dm 1.2.1. Деплоим. Работает. Скажем так — я бы не стал поднимать одновременно два контекста spring-dm и блюпринт в одном бандле. Но в целом вполне живое.

Ну и кого волнует тот факт, что авторы этот продукт забросили, если его функциональность как была написана много лет назад, так и остается в том же виде? Меня? Ни в малейшей степени.
По большому счету OSGI это средство для создания Java-приложений из модулей. Близким аналогом можно считать, например JavaEE, и в какой-то степени OSGI контейнеры могут выполнять JavaEE модули (скажем, web-приложения в виде War), а с другой стороны, многие JavaEE контейнеры содержат OSGI внутри, как средство реализации модульности «для себя». То есть, JavaEE и OSGI — это вещи похожие до совместимости, и удачно взаимодополняющие.

Я б поостерегся проводить такие жирные аналогии между OSGi и JavaEE. Две совершенно разные вещи что по принципам работы, что по решаемым задачам. Karaf/ServiceMix еще куда ни шло. И то они один пень они не сертифицированные EE контейнеры, никогда ими не были, и никогда оными не планировались, что тоже к проведению аналогий не располагает.


OSGi лежит в основе кучи EEшных контейнеров — да. Некоторый набор EEшных спек-имплементаций упакован в бандлы и доступен как фичи в Карафе — да. Но не более того.


А вообще, спасибо за пост. Люблю OSGi.

>Я б поостерегся проводить такие жирные аналогии между OSGi и JavaEE.
Вообще, имелась в виду в основном простая вещь — и то, и другое есть средство организации программ. Из модулей. Разные принципы и задачи? Ну так на то есть раздел про различия.

>Но не более того
Ну, я вроде и не обещал. Цель была в том, чтобы показать, что на верхнем уровне есть некоторое сходство. Насчет того, что сравнивать с JavaEE нужно например Karaf, а не OSGI — то да, тут вы вероятно правы.
> И то, и другое есть средство организации программ. Из модулей

Ну вот это я бы как раз поостерегся утверждать. По крайней мере в вводном посту к OSGi такие сравнения точно ни к чему. Эдак все подходы и парадигмы в истории на модульность можно натянуть — мол, мы класс придумали чтоб бить приложение на такие вот реюзабельные модули… А потом приходят люди и говорят «зачем мне это в 2019, когда я на микросервисах слабать тожсамое могу». А потому что нифига это не тожсамое :)
>Эдак все подходы и парадигмы в истории
Ну, по большей части вся история развития программирования — это борьба со сложностью. В том числе — в виде разбиения ее на мелкие части, и поедания слона по кусочкам.

И конечно они нифига не тоже самое, но это не значит, что общих целей у них совсем-совсем нет.

Берём OSGi, Karaf и используем это во вроде готовом пакете ServiceMix без наличия бекграунда у всей команды… огребаем от странного треша по резолву зависимостей (нигде в интернете решения проблемы найти не удалось, доки и исходники не помогли понять, как с этим бороться) и больше в сторону OSGi не смотрим. Спасибо проходили. Ни документации толковой, ни статей — найти не удалось. Дело было 3 года назад, может что и изменилось, но не верю © сами-знаете-кто.

Я не знаю, какой ответ вы хотели получить… проблемы ресолва зависимостей? Вы думаете, я их не видел? Да так примерно раз в неделю возникали постоянно. Ничего страшного.

Хотите сказать, что это я такой умный? Это лестно, разумеется (шаркает ножкой и раскланивается :), но я думаю дело все-таки не в этом. Вот скажем простой способ — форум карафа. Там вполне дружелюбный народ, который вполне себе помогает с подобными и более сложными проблемами. Так что не верю (с) — это скорее моя реплика :)

Просто интересно, вы сталкивались с ситуацией, когда при резолве зависимостей для модуля SM уходит в StackOverflowException? Тупо потому, что ищет среди модулей устанавливаемый модуль? Т.е. в бесконечном цикле ищет в списках установленных модулей — не находит, ещё в каких-то списках — исключая текущий устанавливаемый модуль (там он, кстати, был), потом рекурсивно вызывает эту же функцию резолва зависимостей… И так до попадания в SOE? Времени тогда разбираться особо не было, имеющеяся документация и инфа в интернете за неделю с проблемой разобраться не позволили… в итоге эксперимент выпилили и не стали с ним дальше заморачиваться.

Не — такого я за 3.5 года не видел. Догадываюсь, что это была бы неприятная штука. А на какой версии карафа это происходило?
Строго говоря, я ServiceMix видел только в теории — у нас либо чистый karaf (3.х), либо Fuse 6.х (тот что на карафе 2.х).
Очень интересно, пишем эклипс плагины, но о таком гораздо широком использовании OSGi не задумывался.
«OSGI это сложно» — можно ли как-то резюмировать, за счет чего сложность и что изменилось, что можно использовать чтобы с этой сложностью справиться?
Я бы сказал, что когда я впервые видел эквинокс, не было в первую очередь bnd плагина, который позволил построить манифест из pom, таким образом, что разработка вообще перестала отличаться от обычной.

Ну и во-вторую (но не по важности) собственно не было карафа. Что эквинокс, что felix, сами по себе, значительно менее удобны в работе, чем karaf.
sshikov, спасибо за статью!
Помимо прочего, Gemini Blueprint используется в Jira (Apache Felix). Хотя, очевидно, что Jira в целом использует довольно устаревший стек технологий, но разработчикам плагинов ничего не остается, кроме как разбираться в перипетиях OSGi. А данная статья весьма полезна для ознакомления с ним.
На здоровье. Только я хочу вас предупредить, что этот текст — он про караф. Это далеко не тоже самое, что феликс сам по себе. Многие вещи делаются карафом, и что у вас будет в JIRA — точно сказать могут только авторы.

sshikov, спасибо за статью, очень в нужное время.
А если конфиг спринга написан на аннотациях, а не в xml?
И как обстоят дела с использованием спринговых бинов из контекста одного бандла, в другом?

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

Явно экспортировать, это, к примеру, при помощи felix-maven-plugin?
По поводу аннотаций, везде в документации карафа, да и у вас в статье тоже, фигурирует xml контекст спринга. Для меня до конца не понятно, каким образом и в какой последовательности караф деплоит бандл, какие условия должны быть осуществлены для того, что бы были удовлетворены внешние зависимости и внутренние (между бандлами) и какую роль в этом играет, например, блюпринт. Толкового материала найти не удается, про osgi вообще не слышал до предыдущего месяца. Поэтому был бы благодарен вам за информацию или полезную ссылку.

>Явно экспортировать, это, к примеру, при помощи felix-maven-plugin?
Ну в том числе и так.

В spring-dm есть соответствующие средства, аналогичные приведенному выше примеру для блюпринта. Ну т.е., в контексте есть бин, вы его можете экспортировать как сервис, указав, что именно экспортируется — какой-то из интерфейсов, либо класс. И задав атрибуты для последующего поиска, если нужно.

>Для меня до конца не понятно, каким образом и в какой последовательности караф деплоит бандл
У бандла просто есть зависимости — сервисы и пакеты. В процессе деплоя караф пытается их разрешить. На момент деплоя они либо есть, либо их нет. В зависимости от этого бандл оказывается в разном статусе. Если все обязательные зависимости разрешились — бандл можно запустить.

> и какую роль в этом играет, например, блюпринт.
По сути, блюпринт (и spring-dm) играет роль описания структуры бандла. Т.е. что за классы (экземпляры) в него входят, как они создаются, что импортируется и экспортируется.

>Поэтому был бы благодарен вам за информацию или полезную ссылку.
Есть же книжка по карафу. Вроде вполне вменяемая была.

А еще я бы посоветовал посмотреть примеры в самом карафе и в camel — там тоже были проекты, где camel деплоится в караф. Они вполне несложные для начала.

Большое спасибо за развернутый ответ.
Про книжку только сейчас додумался, вроде по osgi есть литература. Примеры тоже конечно гляну.

Статья очень старая. Тем не менее, опишу свой путь.
Как и многие, я начинал со Spring и Blueprint.
Не стартовавшие компоненты, висящие в постоянном статусе запуска. Главная причина — отсутствие описания связывания компонентов друг с другом. Есть API сервиса, есть реализация сервиса, есть потребитель. Потребитель стартует раньше и ждет запуска реализации. Подождал и завис. Ни ответа, ни привета.
Неправильная система слежения изменения конфигурации. Создание proxy оболочек над классами не дает воспользоваться новыми свойствами сервиса.
Всё это было. Было мучительно. Перешел на механизм динамических сервисов. Получил набор аннотации org.osgi.service.component.annotations для описания параметров сервиса и описания зависимостей от других сервисов. На уровне framework идет распознание запуска потребителя и реализации.
В потребителе, на уровне активации компонента (@Activate) идет создание и запуск Apache Camel маршрутов. На уровне остановки компонента (@Deactivate) выполняется остановка Apache Camel маршрутов.
Теперь, при изменении настроек реализации сервиса происходит остановка и запуск потребителя.
Если реализация сервиса настроена неправильно, потребитель не запустится и не зависнет в режиме постоянного ожидания, как в Spring DM или Blueprint. Настроил параметры реализация сервиса, потребители стартуют автоматически.
В маршрутах Apache Camel очень часто используются cron. Для профилактических нужд приходится менять расписание доступа к внешним серверам. В конфигурации компонента (Component) меняем параметры cron. Компонент, на уровне изменения (@Modified) производит остановку и запуск Apache Camel маршрутов.
При всех манипуляциях перезапуска маршрутов, система не выкидывает старых процессов обработки данных, давая им время завершится. При этом, новые данные, на стадии остановки, не обрабатываются.

В затрагиваемой технологии микросервисов я так и не нашел решения плавной остановки этих самых микросервисов.
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.