Ответ 1

Какие преимущества предоставляет система компонентов OSGi?
Ну, вот список:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Ответ 2

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

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

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

Ответ 3

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

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

Ответ 4

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

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

Ответ 5

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

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

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

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

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

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

Ответ 6

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

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

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

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

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

И тем, кто рекламирует hotplugging.. OSGi # 1 Client? Затмение. Что делает Eclipse после загрузки пакета?

Перезапускается.

Ответ 7

Я еще не буду "поклонником" OSGi...

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

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

окончательно развернута и "следующие пакеты будут завершены, а затем перезапущены" [2/18/14 9: 38: 33: 108 EST] 00000143 AriesApplicat я CWSAI0054I: как часть операции обновления для приложения

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

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

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

Ответ 8

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

<сильные > Примеры:

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

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

Ответ 9

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

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

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

Ответ 10

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

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

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

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

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

Ответ 11

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

Ответ 12

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

Ответ 13

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

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

Ответ 14

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

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

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

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

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

Ответ 15

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

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