Что нового в OSGi 4.2?

Ответ 1

В большинстве случаев точечный выпуск OSGi (например, 4.1- > 4.2) на самом деле не изменяет много существующего поведения, поэтому можно с уверенностью сказать, что если у вас есть приложение, зависящее от 4.1, оно будет работать на 4.2 без проблем. Новым является то, что несколько элементов стандартизованы, что должно обеспечить лучшую совместимость между различными двигателями OSGi (например, Equinox, Felix и Knopflerfish).

Фактически, хотя OSGi 4.2 был официально выпущен только 16 сентября 2009 года, ранние проекты были доступны для других, чтобы ссылаться на них, поэтому предыдущие выпуски продуктов (например, Equinox 3.5, Felix 1.8) уже имеют разумную поддержку для стандарт. Как и продукты 802.11n, они соответствовали более ранним черновикам, но ожидается, что они будут сертифицированы как полностью совместимые с выпуском 4.2 в не слишком отдаленном будущем.

Итак, что нового в 4.2?

• Крюки для обслуживания
• Рамки запуска

И, в компендиуме

• Удаленные службы
• Bundle Tracker
• Служба Blueprint

Сервисные крюки

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

Запуск платформы

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

Удаленные службы

API удаленных служб позволяет службам OGSi осуществлять связь между виртуальными машинами (возможно, на разных машинах). Точный механизм взаимодействия (RMI, WebServices и т.д.) Открыт для поставщиков, поэтому он отличается от других распределенных технологий (например, Corba), которые конкретно определяют формат проводки. Очевидно, что распределенные службы имеют разную семантику, чем локальные (ошибки связи, проблемы сериализации), и при необходимости отдельные дистрибутивы могут быть распределены.

Bundle Tracker

Как и ServiceTracker перед ним в 4.1, BundleTracker можно использовать, чтобы следить за тем, какие пакеты приходят и уходят в систему. Это может использоваться динамическими GUI, чтобы показать развивающееся состояние OSGi без каких-либо знаний о платформе.

Служба Blueprint

Служба чертежа похожа на Spring, поскольку она обеспечивает механизм впрыска зависимостей для настройки пакетов. В некоторых отношениях это похоже на декларативные услуги; но служба печати делает все по-другому. Кроме того, в отличие от декларативных сервисов (которые могут иметь дело только с имеющимися услугами), служба чертежа может заранее создать прокси-заполнитель для службы, которая будет представлена ​​позже. Затем вызовы прокси-сервера службы блокируются до тех пор, пока служба не будет заполнена (вместо того, чтобы возвращать "нуль", как это делают декларативные службы). Если вам удобно или хорошо знакомы с Spring IOC и аналогичной инъекцией зависимостей, тогда служба Blueprint будет сразу понятна.

Ответ 2

В этой статье обсуждаются интересные RFC. Процитируем,

Прежде всего, нужно заметить, что это не незначительный выпуск, поскольку номер версии может предложить. Выпуск 4.2 на самом деле намного более значителен, чем релиз R4.1 в прошлом году. В некоторые моменты я бы даже сказал, что это более важным, чем релиз R4, потому что при этом одно использование становится путь проще, особенно ни для кого Эксперты OSGi.

Ответ 3

Ранние изменения были выделены здесь.

В частности, интересна функция RFC 119 - Distributed OSGi:

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

В сочетании с EventAdmin (представленный в 41) позволит упростить реализацию распределенных служб на основе OSGi (в настоящее время реализовано с ECF)

Ответ 4

Действительно ли декларативные службы возвращают значение null, когда ссылочное связывание недоступно? В случае равноденствия, даже если я настрою режим на динамический, мой компонент никогда не инстанцируется, если он не может быть "подключен". Я предпочел бы, чтобы он установил значение "null", как вы говорите, так что я мог бы иметь необязательные ссылки привязки и использовать динамическое обнаружение...

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