Я читал в Википедии и на других сайтах об OSGi , но я не вижу общей картины. В нем говорится, что это основанная на компонентах платформа, и что вы можете перезагрузить модули во время выполнения. Также «практическим примером», приведенным везде, является Eclipse Plugin Framework.

Мои вопросы:

1. Каково четкое и простое определение OSGi?

2. Какие общие проблемы это решает?

Под «общими проблемами» я подразумеваю проблемы, с которыми мы сталкиваемся каждый день, например: «Что OSGi может сделать, чтобы сделать нашу работу более эффективной / веселой / простой?»

Какие преимущества дает вам система компонентов 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 функционировать со своей собственной библиотекой. Хотя не рекомендуется проектировать системы с этой проблемой управления версиями, в некоторых случаях это может быть спасением.

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

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

Быстро - Одна из основных обязанностей платформы 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 «public», но и с точки зрения вашей библиотеки / module: Какие (именно) компоненты вы хотите сделать доступными для других? Какие (именно) интерфейсы (других модулей) вам действительно необходимы для реализации вашей функциональности?

Приятно, что с ним поставляется hotplug, но я бы лучше перезапустил свои обычные приложения, чем тестировал все комбинации hotplugability ...

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

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

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

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

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

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

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

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

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

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

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

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

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

И тем из вас, кто рекламирует горячее подключение ... Клиент OSGi # 1? Затмение. Что делает 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 Framework прекратил поддержку пружинных пакетов OSGI, считая это ненужной сложностью для приложений на основе транзакций или для некоторой точки в этих строках. Лично я не рассматриваю OSGI, если это абсолютно необходимо, в чем-то большом, например, в создании платформы.

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

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 .