Comments 51
Итак, допустим вы решили попробовать OSGI на платформе Karaf
А зачем уж я это решил в 2019 году, напомните мне? :)
В век-то выстреливших микросервисов и такого прочего..
>В век-то выстреливших микросервисов
Вообще-то, karaf как раз и есть отличная среда для этих самых микросервисов. Которая обеспечивает им определенный уровень изоляции, с одной стороны, и в тоже время, определенный уровень централизованного управления, развертывания, мониторинга и прочего. Я вполне себе разворачивал проект, содержащий десятки своих бандлов, силами одного человека, то есть меня. И силами небольшой команды — шину на сотни сервисов.
То есть, говоря по-простому, имея под рукой karaf, мне вообще микросервисы как таковые и не нужны — потому что бандл это и есть микросервис. Ну, с некоторыми понятными ограничениями на платформу, т.е. все микросервисы будут под JVM, а не написаны на условном Go или питоне.
А если у вас скажем есть микросервисы, то вам все эти проблемы (управления, развертывания, мониторинга) так или иначе все равно придется решать. И для меня скажем далеко не факт, что будет лучше. У разных вариантов есть свои преимущества и недостатки.
>такого прочего.
Вот тут можно поподробнее, какого «такого прочего»?
А какая область применимости OSGI и какая область применимости JPMS?
Можете себе представить разработку скажем ESB на основе JPMS? Т.е. контейнер, куда в runtime добавляются модули, запускаются, останавливаются, каждому из них нужны зависимости, которые тоже динамически устанавливаются и разрешаются (в случае карафа — например из maven репозитория). Я не вижу вообще, каким боком сюда JPMS.
Реальная область применимости OSGI — это куча JavaEE и ESB, которые на нем основаны.
А у JPMS какая?
Можете себе представить разработку скажем ESB на основе JPMS?
Вообще не очень, но может это из-за того, что я с JPMS толком не работал.
Например маленький, что было бы неплохо для мобильных железок или embedded.
Очевидно, что к очень многим областям, которые покрывает OSGI (например, условный JNDI и вообще Java EE), и ко всей части DI (blueprint в том числе) это просто никакого отношения не имеет.
Очевидно, что к очень многим областям, которые покрывает OSGI, например, ко всей части DI, JPMS отношения не имеет.
Я тут подумал, получается, что имеет. Один из механизмов DI — java.util.ServiceLoader и он связан с модулями напрямую.
Есть правда неудобство с конфигурированием профилей, не очень удобно делать это через консоль. Веб морда лагучая, hawtio тож тормозит при работе через jms. Проблему решили написав и установив бандл на корневой инстанс, работающий с сервисами фьюза напрямую.
Но поскольку все бандлы уже есть в JMX в виде MBeans, а JMX доступен по сети небольшими усилиями (ну, скажем, чтобы совсем кто попало не лазал, нужно кое-какую авторизацию и ролевую модель), то дальше берем groovy в руки, GroovyMbean, и за 15 минут прикрутил внешний мониторинг, например, с выходом на Nagios.
Вот пример мнения от 2016 года, тогда это не выглядело как свершившийся триумф, и мое мнение тогда практически совпадало с мнением автора.
Понятно что условные докер или kubernetes развивались, не стояли на месте. Что-то изменилось принципиально? Какие-то из описанных тогда проблем кардинально решены?
что-то кроме карафа, эквинокса? spring dm примкнувший к эклипс фаундейшн там и почил, например.
технология не популяризуется, не обрастает удобствами в отличие от микросервисов.
я тыкал osgi, когда оно было только в эквиноксе, когда спрингсорс это начинание подхватил, но потом почему-то в стороночку отложил и аккуратненько забыл. Я наблюдал со стороны за этим и не видел достаточно стабильно нарастающей популярности данной технологии.
Полно. Умный дом, к примеру. На совсем мелких железках.
>spring dm примкнувший к эклипс фаундейшн там и почил, например.
Во-первых, вместо него Blueprint, вы просто пост не очень внимательно прочитали.
А сам spring dm просто живет и здравствует, потому что его работоспособность не нарушилась, и он решает все задачи, какие должен — то есть, мы берем приложение на спринге, обычное, а не DM, деплоим в караф, и о чудо — оно работает! Добавляем чуточку DM, в виде пары таглибов, и оно уже понимает сервисы карафа, или публикует свои.
>аккуратненько забыл.
Об этом и речь, что многие думают как вы. Посмотрели на технологию 10 лет назад (да, она тогда уже была), и решили, что ничего не меняется. Однако менялось. С тех пор разрабатывать под OSGI стало просто и удобно. Месяц на вход. Потом двадцать интеграций разного рода за пару лет, на куче разных механизмов.
Нишевая технология? Ну, с тем же успехом можно считать, что и JavaEE сегодня нишевая. По сравнению с андроид, и его масштабами по числу установок приложений — просто небо и земля. Просто мало кто пишет свои ESB-шины.
про блюпринт, не переживайте, в курсе. ему уже лет десять как… блюпринту этому…
Gemini Blueprint является непосредственным развитием кода spring dm, и официально рекомендуется вместо него. Он не исчез — на его основе написали другой продукт, более современный. Но при этом старый код версии аж 1.2.1, все еще успешно работает. Spring DM конечно легаси, но он никуда не делся.
>про блюпринт, не переживайте, в курсе.
Вот не похоже, чтобы вы знали его историю.
Так что ваши выводы в части spring неверные, и непонятно на чем основаны.
А были. И ушли ровно тогда, когда они это всё отдали в эклипс. После этого проект живет на «энтузиастах опенсорса».
Своими комментариями я совершенно не пытаюсь предать osgi анафеме, сказать, что микросервисы — серебряная пуля, рулят и педалят и т.д.
Но на данный момент osgi — маргинальщина. За сим разрешите откланяться. Дальше я это усугублять не буду :)
P.S.: Кстати, как там r-osgi? не загнулся? :)
Хм. Вот интересно, спрингсорс значит энтерпрайз, а я тогда кто? Мой проект был сделан по заказу FI Desk одного довольно крупного инвестиционного банка. Я и есть самый что ни на есть энтерпрайз, во всей его кровавости, разве нет? :)
Задумался в свое время. И пришел для себя к выводу, что произошло это потому — что всеми так разлюбимый спринг — один большой пучок рантайм-магии с кодогенерацией и рефлексией, а OSGi такие выкрутасы не любит. И вот ИМХО это — спринговый слив, а не OSGiшный.
ESB — есть, микросервисы — есть. А вот osgi я что-то ни у кого не видел в портфеле.
Ну и кого волнует тот факт, что авторы этот продукт забросили, если его функциональность как была написана много лет назад, так и остается в том же виде? Меня? Ни в малейшей степени.
По большому счету OSGI это средство для создания Java-приложений из модулей. Близким аналогом можно считать, например JavaEE, и в какой-то степени OSGI контейнеры могут выполнять JavaEE модули (скажем, web-приложения в виде War), а с другой стороны, многие JavaEE контейнеры содержат OSGI внутри, как средство реализации модульности «для себя». То есть, JavaEE и OSGI — это вещи похожие до совместимости, и удачно взаимодополняющие.
Я б поостерегся проводить такие жирные аналогии между OSGi и JavaEE. Две совершенно разные вещи что по принципам работы, что по решаемым задачам. Karaf/ServiceMix еще куда ни шло. И то они один пень они не сертифицированные EE контейнеры, никогда ими не были, и никогда оными не планировались, что тоже к проведению аналогий не располагает.
OSGi лежит в основе кучи EEшных контейнеров — да. Некоторый набор EEшных спек-имплементаций упакован в бандлы и доступен как фичи в Карафе — да. Но не более того.
А вообще, спасибо за пост. Люблю OSGi.
Вообще, имелась в виду в основном простая вещь — и то, и другое есть средство организации программ. Из модулей. Разные принципы и задачи? Ну так на то есть раздел про различия.
>Но не более того
Ну, я вроде и не обещал. Цель была в том, чтобы показать, что на верхнем уровне есть некоторое сходство. Насчет того, что сравнивать с JavaEE нужно например Karaf, а не OSGI — то да, тут вы вероятно правы.
Ну вот это я бы как раз поостерегся утверждать. По крайней мере в вводном посту к OSGi такие сравнения точно ни к чему. Эдак все подходы и парадигмы в истории на модульность можно натянуть — мол, мы класс придумали чтоб бить приложение на такие вот реюзабельные модули… А потом приходят люди и говорят «зачем мне это в 2019, когда я на микросервисах слабать тожсамое могу». А потому что нифига это не тожсамое :)
Ну, по большей части вся история развития программирования — это борьба со сложностью. В том числе — в виде разбиения ее на мелкие части, и поедания слона по кусочкам.
И конечно они нифига не тоже самое, но это не значит, что общих целей у них совсем-совсем нет.
Берём OSGi, Karaf и используем это во вроде готовом пакете ServiceMix без наличия бекграунда у всей команды… огребаем от странного треша по резолву зависимостей (нигде в интернете решения проблемы найти не удалось, доки и исходники не помогли понять, как с этим бороться) и больше в сторону OSGi не смотрим. Спасибо проходили. Ни документации толковой, ни статей — найти не удалось. Дело было 3 года назад, может что и изменилось, но не верю © сами-знаете-кто.
Хотите сказать, что это я такой умный? Это лестно, разумеется (шаркает ножкой и раскланивается :), но я думаю дело все-таки не в этом. Вот скажем простой способ — форум карафа. Там вполне дружелюбный народ, который вполне себе помогает с подобными и более сложными проблемами. Так что не верю (с) — это скорее моя реплика :)
Просто интересно, вы сталкивались с ситуацией, когда при резолве зависимостей для модуля SM уходит в StackOverflowException? Тупо потому, что ищет среди модулей устанавливаемый модуль? Т.е. в бесконечном цикле ищет в списках установленных модулей — не находит, ещё в каких-то списках — исключая текущий устанавливаемый модуль (там он, кстати, был), потом рекурсивно вызывает эту же функцию резолва зависимостей… И так до попадания в SOE? Времени тогда разбираться особо не было, имеющеяся документация и инфа в интернете за неделю с проблемой разобраться не позволили… в итоге эксперимент выпилили и не стали с ним дальше заморачиваться.
«OSGI это сложно» — можно ли как-то резюмировать, за счет чего сложность и что изменилось, что можно использовать чтобы с этой сложностью справиться?
Ну и во-вторую (но не по важности) собственно не было карафа. Что эквинокс, что felix, сами по себе, значительно менее удобны в работе, чем karaf.
Помимо прочего, Gemini Blueprint используется в Jira (Apache Felix). Хотя, очевидно, что Jira в целом использует довольно устаревший стек технологий, но разработчикам плагинов ничего не остается, кроме как разбираться в перипетиях OSGi. А данная статья весьма полезна для ознакомления с ним.
Явно экспортировать, это, к примеру, при помощи felix-maven-plugin?
По поводу аннотаций, везде в документации карафа, да и у вас в статье тоже, фигурирует xml контекст спринга. Для меня до конца не понятно, каким образом и в какой последовательности караф деплоит бандл, какие условия должны быть осуществлены для того, что бы были удовлетворены внешние зависимости и внутренние (между бандлами) и какую роль в этом играет, например, блюпринт. Толкового материала найти не удается, про osgi вообще не слышал до предыдущего месяца. Поэтому был бы благодарен вам за информацию или полезную ссылку.
Ну в том числе и так.
В spring-dm есть соответствующие средства, аналогичные приведенному выше примеру для блюпринта. Ну т.е., в контексте есть бин, вы его можете экспортировать как сервис, указав, что именно экспортируется — какой-то из интерфейсов, либо класс. И задав атрибуты для последующего поиска, если нужно.
>Для меня до конца не понятно, каким образом и в какой последовательности караф деплоит бандл
У бандла просто есть зависимости — сервисы и пакеты. В процессе деплоя караф пытается их разрешить. На момент деплоя они либо есть, либо их нет. В зависимости от этого бандл оказывается в разном статусе. Если все обязательные зависимости разрешились — бандл можно запустить.
> и какую роль в этом играет, например, блюпринт.
По сути, блюпринт (и spring-dm) играет роль описания структуры бандла. Т.е. что за классы (экземпляры) в него входят, как они создаются, что импортируется и экспортируется.
>Поэтому был бы благодарен вам за информацию или полезную ссылку.
Есть же книжка по карафу. Вроде вполне вменяемая была.
А еще я бы посоветовал посмотреть примеры в самом карафе и в camel — там тоже были проекты, где camel деплоится в караф. Они вполне несложные для начала.
Как и многие, я начинал со 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 маршрутов.
При всех манипуляциях перезапуска маршрутов, система не выкидывает старых процессов обработки данных, давая им время завершится. При этом, новые данные, на стадии остановки, не обрабатываются.
В затрагиваемой технологии микросервисов я так и не нашел решения плавной остановки этих самых микросервисов.
Внедряем OSGI на платформе Karaf