Какие преимущества дает вам компонентная система 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 VM для запуска и добавляет очень мало поверх нее.
Быстрый - Одна из основных обязанностей платформы OSGi - загрузка классов из пакетов. В традиционной Java файлы JAR полностью видны и помещаются в линейный список. Поиск в классе требует поиска по этому (часто очень длинному, 150 - нередкому) списку. Напротив, OSGi предварительно связывает пакеты и знает для каждого пакета точно, какой пакет предоставляет класс. Это отсутствие поиска является существенным фактором ускорения при запуске.
Ленивый - Ленивый в программном обеспечении хорош, а технология OSGi имеет множество механизмов, позволяющих делать вещи только тогда, когда они действительно необходимы. Например, пакеты могут быть запущены с нетерпением, но они также могут быть настроены на запуск только тогда, когда другие пакеты используют их. Сервисы могут быть зарегистрированы, но созданы только тогда, когда они используются. Спецификации были оптимизированы несколько раз, чтобы учесть такие ленивые сценарии, которые могут сэкономить огромные затраты времени выполнения.
Безопасный - Внизу Java имеет очень мощную детальную модель безопасности, но на практике оказалось, что ее очень сложно настроить. В результате большинство защищенных Java-приложений работают с двоичным выбором: без защиты или с очень ограниченными возможностями. Модель безопасности OSGi использует детализированную модель безопасности, но повышает удобство использования (а также ужесточает исходную модель), позволяя разработчику пакета указывать запрошенные детали безопасности в легко проверяемой форме, пока оператор среды остается полностью ответственным. В целом, OSGi, вероятно, предоставляет одну из самых безопасных сред приложений, которая по-прежнему пригодна для использования, за исключением аппаратно защищенных вычислительных платформ.
Non Intrusive - Приложения (комплекты) в среде OSGi оставлены на свое усмотрение. Они могут использовать практически любое средство виртуальной машины без ограничения OSGi. В OSGi рекомендуется писать простые старые объекты Java, поэтому для служб OSGi не требуется специального интерфейса, даже объект Java String может выступать в качестве службы OSGi. Эта стратегия упрощает перенос кода приложения в другую среду.
Работает везде - Ну, это зависит. Первоначальная цель Java состояла в том, чтобы бежать куда угодно. Очевидно, что невозможно выполнить весь код везде, потому что возможности виртуальных машин Java отличаются. Виртуальная машина в мобильном телефоне, вероятно, не будет поддерживать те же библиотеки, что и мэйнфрейм IBM, на котором запущено банковское приложение. Есть две проблемы, о которых нужно позаботиться. Во-первых, API OSGi не должны использовать классы, которые доступны не во всех средах. Во-вторых, пакет не должен запускаться, если он содержит код, который недоступен в среде выполнения. Обе эти проблемы были учтены в спецификациях OSGi.
Источник: www.osgi.org / Технология / WhyOSGi