Что решает OSGi?
================

 

**what benefits does OSGi's component system provide you?   
Well, Here is quite a list:**
**Reduced Complexity -** Разработка с использованием технологии OSGi означает разработку пакетов: компонентов OSGi. Связки - это модули. Они прячут свои внутренние устройства от других групп и общаются через четко определенные сервисы. Сокрытие внутренних органов означает больше свободы, чтобы измениться позже. Это не только уменьшает количество ошибок, но и упрощает разработку пакетов, поскольку пакеты правильного размера реализуют часть функциональности через четко определенные интерфейсы. Есть интересный блог, в котором рассказывается о том, что технология OSGi сделала для процесса разработки.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Источник :[www.osgi.org/Technology/WhyOSGi](http://www.osgi.org/Technology/WhyOSGi)



По крайней мере, OSGi заставляет вас ДУМАТЬ о модульности, повторном использовании кода, управлении версиями и вообще о проекте.



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

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

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



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

**Examples**:

**Eclipse**: Provides platform for plugins to install, uninstall, update and inter-depend.
**AEM**: WCM application, where functionality change will be business driven, which can not afford down times for maintenance.

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



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

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

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

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

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

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

Это перезапускается.



edited for clarity. OSGi page gave a better simple answer than mine

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

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

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

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

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



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

& # X25A0; Переносимая и безопасная среда исполнения на основе Java

& # X25A0; Система управления услугами, которая может использоваться для регистрации и обмена услугами между пакетами и отделения поставщиков услуг от потребителей услуг

& # X25A0; Динамическая модульная система, которая может использоваться для динамической установки и удаления
Модули Java, которые OSGi называет пакетами

& # X25A0; Легкое и масштабируемое решение



Я еще не стал "фанатом" ОСГи ...

Я работал с корпоративным приложением в 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. По крайней мере, это мой опыт до сих пор.



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

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



You can, analogically speaking, change the motor of your car without turning it off.
You can customize complex systems for the customers. See the power of Eclipse.
You can reuse entire components. Better than just objects.
You use a stable platform to develop component based Applications. The benefits of this are huge.
You can build Components with the black box concept. Other components don't need to know about hidden interfaces, them see just the published interfaces.
You can use in the same system several equal components, but in different releases, without compromise the application. OSGi solves the Jar Hell problem.
With OSGi you develop thinking to architect systems with [CBD](https://en.wikipedia.org/wiki/Component-based_software_engineering)
Есть много преимуществ (я напомнил только сейчас), доступных для всех, кто использует Java.



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

In one of our application, we have event based flow and flow is defined in plugins based on OSGi platform so tomorrow if some client wants different/additional flow then he just have to deploy one more plugin, configure it from our console and he is done.
It is used for deploying different Store connectors, for example, suppose we already have Oracle DB connector and tomorrow mongodb is required to be connected then write a new connector and deploy it and configure the details through console and again you are done. deployment of connnectors is handled by OSGi plugin framework.


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



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

Each plugin is a versioned artifact that has its own classloader.
Each plugin depends on both specific jars that it contains and also other specific versioned plug-ins.
Because of the versioning and isolated classloaders, different versions of the same artifact can be loaded at the same time. If one component of your application relies on one version of a plug-in and another depends on another version, they both can be loaded at the same time.

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