Какие преимущества дает вам система компонентов OSGi?
Что ж, вот и целый список:

Пониженная сложность - Разработка с использованием технологии OSGi означает разработку пакетов: компонентов OSGi. Связки - это модули. Они скрывают свои внутренние компоненты от других пакетов и общаются через четко определенные службы. Скрытие внутренних компонентов означает больше свободы для внесения изменений в дальнейшем. Это не только уменьшает количество ошибок, но и упрощает разработку пакетов, поскольку пакеты правильного размера реализуют часть функциональности через четко определенные интерфейсы. Есть интересный блог, в котором описывается, что технология OSGi сделала для процесса их разработки.

Повторное использование - модель компонентов OSGi позволяет очень легко использовать многие сторонние компоненты в приложении. Все большее количество проектов с открытым исходным кодом предоставляют свои JAR-файлы, готовые для OSGi. Однако коммерческие библиотеки также становятся доступными в виде готовых пакетов.

Реальный мир. Структура OSGi динамична. Он может обновлять пакеты на лету, а услуги могут приходить и уходить. Разработчики, привыкшие к более традиционной Java, видят в этом очень проблематичную функцию и не видят преимуществ. Однако оказывается, что реальный мир очень динамичен, и наличие динамических сервисов, которые могут приходить и уходить, делает эти сервисы идеальным вариантом для многих сценариев реального мира. Например, служба может моделировать устройство в сети. Если устройство обнаружено, услуга регистрируется. Если устройство уходит, значит услуга отменяется. Существует удивительное количество реальных сценариев, которые соответствуют этой динамической модели обслуживания. Таким образом, приложения могут повторно использовать мощные примитивы реестра служб (регистрация, получение, список с помощью выразительного языка фильтров и ожидание появления и исчезновения служб) в своем собственном домене. Это не только экономит время на написание кода, но и обеспечивает глобальную видимость, инструменты отладки и большую функциональность, чем было бы реализовано для специального решения. Написание кода в такой динамической среде звучит как кошмар, но, к счастью, существуют классы поддержки и фреймворки, которые снимают большую часть, если не всю, боль.

Простое развертывание. Технология OSGi - это не просто стандарт для компонентов. Он также определяет, как компоненты устанавливаются и управляются. Этот API использовался многими пакетами для предоставления агента управления. Этот агент управления может быть таким же простым, как командная оболочка, драйвер протокола управления TR-69, драйвер протокола OMA DM, интерфейс облачных вычислений для Amazon EC2 или система управления IBM Tivoli. Стандартизированный API управления позволяет очень легко интегрировать технологию OSGi в существующие и будущие системы.

Динамические обновления. Модель компонентов OSGi - это динамическая модель. Пакеты можно устанавливать, запускать, останавливать, обновлять и удалять без остановки всей системы. Многие разработчики Java не верят, что это можно сделать надежно, и поэтому изначально не используют это в производственной среде. Однако, после использования этого в течение некоторого времени в разработке, большинство начинает понимать, что это действительно работает и значительно сокращает время развертывания.

Адаптивная - модель компонентов OSGi разработана с нуля, чтобы позволить смешивать и согласовывать компоненты. Для этого необходимо указать зависимости компонентов, а также необходимо, чтобы компоненты находились в среде, в которой их дополнительные зависимости не всегда доступны. Реестр служб OSGi - это динамический реестр, в котором пакеты могут регистрировать, получать и прослушивать службы. Эта динамическая модель обслуживания позволяет пакетам узнавать, какие возможности доступны в системе, и адаптировать функциональность, которую они могут предоставить. Это делает код более гибким и устойчивым к изменениям.

Прозрачность. Пакеты и услуги - это первоклассные продукты в среде OSGi. API управления предоставляет доступ к внутреннему состоянию пакета, а также к тому, как он связан с другими пакетами. Например, большинство фреймворков предоставляют командную оболочку, которая показывает это внутреннее состояние. Части приложений могут быть остановлены для отладки определенной проблемы или могут быть добавлены диагностические пакеты. Вместо того, чтобы смотреть на миллионы строк выходных данных журнала и длительное время перезагрузки, приложения OSGi часто можно отлаживать с помощью живой командной оболочки.

Управление версиями - технология OSGi решает проблему JAR. JAR, черт возьми, проблема в том, что библиотека A работает с библиотекой B; версия = 2, но библиотека C может работать только с B; версия = 3. В стандартной Java вам не повезло. В среде OSGi все пакеты тщательно контролируются версиями, и только пакеты, которые могут взаимодействовать, связаны вместе в одном пространстве классов. Это позволяет пакетам A и C работать с собственной библиотекой. Хотя не рекомендуется разрабатывать системы с этой проблемой управления версиями, в некоторых случаях это может спасти жизнь.

Просто. OSGi API на удивление прост. Ядро API - это всего лишь один пакет и менее 30 классов / интерфейсов. Этого основного API достаточно для написания пакетов, их установки, запуска, остановки, обновления и удаления, и он включает все классы прослушивателя и безопасности. Очень мало API-интерфейсов, которые предоставляют столько функций для такого небольшого API.

Маленький - OSGi Release 4 Framework может быть реализован в файле JAR размером около 300 КБ. Это небольшие накладные расходы по сравнению с объемом функций, которые добавляются к приложению за счет включения OSGi. Таким образом, OSGi работает на большом количестве устройств: от очень маленьких до мэйнфреймов. Он запрашивает только минимальную виртуальную машину Java для запуска и очень мало добавляет к ней.

Быстро. Одна из основных задач платформы OSGi - загрузка классов из пакетов. В традиционной Java JAR полностью видны и помещаются в линейный список. Поиск класса требует поиска в этом (часто очень длинном, 150 - не редкость) списке. Напротив, OSGi предварительно связывает пакеты и точно знает для каждого пакета, какой пакет предоставляет класс. Отсутствие поиска - существенный фактор ускорения при запуске.

Ленивый - Ленивый в программном обеспечении - это хорошо, и технология OSGi имеет множество механизмов, позволяющих выполнять действия только тогда, когда они действительно необходимы. Например, пакеты можно запускать быстро, но их также можно настроить так, чтобы они запускались только тогда, когда их используют другие пакеты. Услуги могут быть зарегистрированы, но созданы только тогда, когда они используются. Спецификации были оптимизированы несколько раз, чтобы учесть такие ленивые сценарии, которые могут сэкономить огромные затраты времени выполнения.

Безопасность - Java имеет очень мощную детализированную модель безопасности в нижней части, но оказалось, что ее очень сложно настроить на практике. В результате большинство безопасных приложений Java работают с двоичным выбором: отсутствие безопасности или очень ограниченные возможности. Модель безопасности OSGi использует детализированную модель безопасности, но повышает удобство использования (а также укрепляет исходную модель) за счет того, что разработчик пакета указывает запрошенные детали безопасности в легко проверяемой форме, в то время как оператор среды остается полностью ответственным. В целом, OSGi, вероятно, предоставляет одну из самых безопасных сред приложений, которую можно использовать, если не считать аппаратно защищенных вычислительных платформ.

Без вмешательства. Приложения (пакеты) в среде OSGi предоставлены сами себе. Они могут использовать практически любые средства виртуальной машины без ограничения OSGi. Лучшая практика в OSGi - писать простые старые объекты Java, и по этой причине для служб OSGi не требуется специального интерфейса, даже объект Java String может действовать как служба OSGi. Эта стратегия упрощает перенос кода приложения в другую среду.

Работает везде - Это зависит от многого. Первоначальной целью Java было запускать где угодно. Очевидно, что невозможно запустить весь код везде, потому что возможности виртуальных машин Java различаются. Виртуальная машина в мобильном телефоне, скорее всего, не будет поддерживать те же библиотеки, что и мэйнфрейм IBM, на котором запущено банковское приложение. Есть две проблемы, о которых нужно позаботиться. Во-первых, API OSGi не должны использовать классы, которые доступны не во всех средах. Во-вторых, пакет не должен запускаться, если он содержит код, недоступный в среде выполнения. Обе эти проблемы учтены в спецификациях OSGi.

Источник: www.osgi.org/Technology/WhyOSGi.

Я обнаружил следующие преимущества OSGi:

• Каждый плагин - это артефакт с версией, у которого есть собственный загрузчик классов.
• Каждый подключаемый модуль зависит как от конкретных jar-файлов, которые он содержит, так и от других подключаемых модулей с определенными версиями.
• Из-за управления версиями и изолированных загрузчиков классов одновременно могут быть загружены разные версии одного и того же артефакта. Если один компонент вашего приложения зависит от одной версии подключаемого модуля, а другой зависит от другой версии, они оба могут быть загружены одновременно.

Благодаря этому вы можете структурировать свое приложение как набор артефактов подключаемых модулей с поддержкой версий, которые загружаются по запросу. Каждый плагин представляет собой отдельный компонент. Подобно тому, как Maven помогает вам структурировать вашу сборку, чтобы она была повторяемой и определялась набором определенных версий артефактов, которые она создает, OSGi помогает вам делать это во время выполнения.

Меня не слишком заботит возможность горячего подключения модулей OSGi (по крайней мере, в настоящее время). Это скорее принудительная модульность. Отсутствие миллионов «общедоступных» классов, доступных в пути к классам в любое время, хорошо защищает от циклических зависимостей: вы должны серьезно подумать о своих общедоступных интерфейсах - не только с точки зрения конструкции языка Java «общедоступный», но и с точки зрения вашей библиотеки / module: Какие (именно) компоненты вы хотите сделать доступными для других? Какие (именно) интерфейсы (других модулей) вам действительно нужны для реализации вашей функциональности?

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

• Вы можете, аналогично говоря, поменять мотор вашего автомобиля, не выключая его.
• Вы можете настраивать сложные системы для клиентов. Посмотрите на мощь Eclipse.
• Вы можете повторно использовать целые компоненты. Лучше, чем просто предметы.
• Вы используете стабильную платформу для разработки приложений на основе компонентов. Преимущества этого огромны.
• Вы можете создавать Компоненты с концепцией черного ящика. Другим компонентам не нужно знать о скрытых интерфейсах, они видят только опубликованные интерфейсы.
• Вы можете использовать в одной системе несколько одинаковых компонентов, но в разных выпусках, без ущерба для приложения. OSGi решает проблему Jar Hell.
• С OSGi вы развиваете мышление для создания архитектуры систем с помощью CBD

Есть много преимуществ (я напомнил только об этом), доступных для всех, кто использует Java.

отредактировано для ясности. Страница OSGi дала лучший простой ответ, чем моя

Простой ответ: сервисная платформа OSGi предоставляет стандартизированную компонентно-ориентированную вычислительную среду для взаимодействия сетевых сервисов. Эта архитектура значительно снижает общую сложность создания, обслуживания и развертывания приложений. Платформа OSGi Service Platform предоставляет функции для динамического изменения состава на устройстве в различных сетях без перезапуска.

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

Опять же, не проблема для повседневного использования в небольших приложениях.

Но когда вы начинаете смотреть на мультикомпьютерные распределенные инфраструктуры приложений, это становится интересным. Когда вам необходимо обеспечить 100% безотказную работу критически важных систем, полезна возможность горячей замены компонентов или добавления новых функций во время выполнения. Конечно, сейчас для этого есть по большей части возможности, но OSGi пытается объединить все в симпатичную небольшую структуру с общими интерфейсами.

Решает ли OSGi типичные проблемы, я не уверен в этом. Я имею в виду, что может, но накладные расходы могут не окупиться для более простых задач. Но это следует учитывать, когда вы начинаете иметь дело с более крупными сетевыми приложениями.

Несколько вещей, которые сводят меня с ума от OSGi:

1) Реализации и их загрузчики контекста имеют много причуд и могут быть несколько асинхронными (мы используем felix внутри confluence). По сравнению с чистым Spring (без DM), где [main] в значительной степени выполняет синхронизацию всего.

2) После горячей нагрузки классы не равны. Скажем, например, у вас есть кеш-слой tangosol в спящем режиме. Он заполнен Fork.class, выходящим за рамки OSGi. Вы загружаете новую банку, а вилка не изменилась. Класс [Вилка]! = Класс [Вилка]. Он также появляется во время сериализации по тем же причинам.

3) Кластеризация.

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

А тем из вас, кто рекламирует горячее подключение .. Клиент №1 OSGi? Затмение. Что делает Eclipse после загрузки пакета?

Он перезапускается.

OSGi заставляет ваш код бросать NoClassDefFoundError и ClassNotFoundException без видимой причины (скорее всего, из-за того, что вы забыли экспортировать пакет в файл конфигурации OSGi); поскольку у него есть ClassLoaders, он может привести к тому, что ваш класс com.example.Foo не сможет быть преобразован в com.example.Foo, поскольку на самом деле это два разных класса, загруженные двумя разными загрузчиками классов. Он может заставить ваш Eclipse загрузиться в консоль OSGi после установки подключаемого модуля Eclipse.

Для меня OSGi только добавила сложности (потому что добавила еще одну ментальную модель для меня), добавила неприятностей из-за исключений; Мне никогда особо не требовалась динамичность, которую он «предлагает». Это было навязчиво, поскольку требовало конфигурации комплекта OSGi для всех модулей; это было определенно непросто (в более крупном проекте).

Из-за моего плохого опыта я стараюсь держаться подальше от этого монстра, большое вам спасибо. Я бы предпочел страдать от ада jar-зависимостей, так как это намного проще понять, чем ад загрузчиков классов, который вводит OSGi.

Я еще не был "фанатом" OSGi ...

Я работал с корпоративным приложением в компаниях из списка Fortune 100. Недавно используемый нами продукт был «обновлен» до реализации OSGi.

запуск локального развертывания cba ... [18.02.14 8: 47: 23: 727 EST] 00000347 CheckForOasis

наконец развернут, и «следующие пакеты будут приостановлены, а затем перезапущены» [18.02.14, 9: 38: 33: 108 EST] 00000143 AriesApplicat I CWSAI0054I: как часть операции обновления для приложения

51 минута ... при каждом изменении кода ... Предыдущая версия (не OSGi) развертывалась менее чем за 5 минут на старых машинах для разработки.

на машине с 16-гигабайтной оперативной памятью и 40-гигабайтным свободным диском и процессором Intel i5-3437U 1,9 ГГц

«Преимущество» этого обновления было продано как улучшающее (производственное) развертывание - деятельность, которую мы выполняем примерно 4 раза в год, возможно, с 2-4 небольшими развертываниями исправлений в год. Добавление 45 минут в день для 15 человек (QA и разработчиков), я не могу представить, чтобы это когда-либо было оправдано. В больших корпоративных приложениях, если ваше приложение является основным приложением, то его изменение является правильным (небольшие изменения могут иметь далеко идущие последствия - они должны сообщаться и планироваться с потребителями по всему предприятию), монументальная деятельность - неправильная архитектура для OSGi. Если ваше приложение не является корпоративным приложением, то есть каждый потребитель может иметь свой собственный адаптированный модуль, который, вероятно, попадает в свой собственный хранилище данных в своей собственной базе данных и работает на сервере, на котором размещено множество приложений, тогда, возможно, посмотрите на OSGi. По крайней мере, таков мой опыт.

Если приложение на основе Java требует добавления или удаления модулей (расширения базовой функциональности приложения), без выключения JVM, можно использовать OSGI. Обычно, если закрытие JVM обходится дороже, просто для обновления или улучшения функциональности.

Примеры:

1. Eclipse: предоставляет платформу для плагинов для установки, удаления, обновления и взаимозависимости.
2. AEM: приложение WCM, в котором изменение функциональности будет зависеть от бизнеса, которое не может позволить себе простои из-за обслуживания.

Примечание. Платформа Spring перестала поддерживать пакеты Spring OSGI, посчитав это ненужной сложностью для приложений на основе транзакций или для некоторых точек в этих строках. Лично я не рассматриваю OSGI, за исключением случаев крайней необходимости, например, для создания платформы.

Я работаю с OSGi почти 8 лет или около того, и я должен сказать, что вам следует рассматривать OSGi только в том случае, если у вас есть бизнес-потребность в обновлении, удалении, установке или замене компонента во время выполнения. Это также означает, что вы должны иметь модульное мышление и понимать, что такое модульность. Есть некоторые аргументы в пользу того, что OSGi является легковесным - да, это правда, но есть также некоторые другие структуры, которые легче и легче поддерживать и развивать. То же самое и с безопасностью Java-бла-бла.

OSGi требует надежной архитектуры для правильного использования, и довольно легко сделать OSGi-систему, которая так же легко могла бы быть автономно-запускаемой-jar без участия OSGi.

OSGi дает следующие преимущества:

■ Переносимая и безопасная среда выполнения на основе Java

■ Система управления услугами, которую можно использовать для регистрации и совместного использования услуг между пакетами и отделения поставщиков услуг от потребителей услуг.

■ Система динамических модулей, которую можно использовать для динамической установки и удаления модулей Java, которые OSGi называет связками.

■ Легкое и масштабируемое решение.

Он также используется для обеспечения дополнительной переносимости промежуточного программного обеспечения и приложений на мобильных устройствах. Мобильная часть доступна, например, для WinMo, Symbian, Android. Как только произойдет интеграция с функциями устройства, может стать фрагментированным.

По крайней мере, OSGi заставляет задуматься о модульности, повторном использовании кода, управлении версиями и в целом о структуре проекта.

Другие уже подробно описали преимущества, а настоящим я объясняю практические варианты использования, которые я видел или использовал OSGi.

1. В одном из наших приложений у нас есть поток, основанный на событиях, и поток определяется в плагинах на основе платформы OSGi, поэтому завтра, если какой-то клиент хочет другой / дополнительный поток, ему просто нужно развернуть еще один плагин, настроить его с нашей консоли, и он готов .
2. Он используется для развертывания различных коннекторов Store, например, предположим, что у нас уже есть коннектор Oracle DB, а завтра потребуется подключение mongodb, затем напишите новый коннектор, разверните его и настройте детали через консоль, и снова все готово. Развертывание коннекторов осуществляется платформой плагинов OSGi.

На его официальном сайте уже есть довольно убедительное заявление, я могу процитировать его:

Основная причина успеха технологии OSGi в том, что она предоставляет очень зрелую компонентную систему, которая действительно работает в удивительном количестве сред. Компонентная система OSGi фактически используется для создания очень сложных приложений, таких как IDE (Eclipse), серверы приложений (GlassFish, IBM Websphere, Oracle / BEA Weblogic, Jonas, JBoss), фреймворки приложений (Spring, Guice), промышленная автоматизация, бытовые шлюзы и т. Д. телефоны и многое другое.

Что касается преимуществ для застройщика?

РАЗРАБОТЧИКАМ: OSGi снижает сложность, предоставляя модульную архитектуру для сегодняшних крупномасштабных распределенных систем, а также небольших встроенных приложений. Сборка систем из собственных и готовых модулей значительно снижает сложность и, следовательно, затраты на разработку и обслуживание. Модель программирования OSGi реализует многообещающие возможности компонентно-ориентированных систем.

Пожалуйста, проверьте подробности в Преимущества использования OSGi.