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

Question

OSGi 4.2 имеет только что был освобожден который обновляет спецификацию 4.1 несколькими новыми RFC.Итак, что особенно нового в OSGi 4.2, какие фреймворки уже поддерживают 4.2 (или близки к этому) и почему вы должны ориентировать новые разработки на фреймворк 4.2, а не 4.1?

Answer 1

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

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

Итак, что нового в версии 4.2?

• Сервисные Крючки
• Запуск фреймворка

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

• Удаленные сервисы
• Отслеживание пакетов
• Служба создания чертежей

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

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

Запуск фреймворка

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

Удаленные сервисы

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

Отслеживание пакетов

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

Служба создания чертежей

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

Answer 2

Эта статья подробно описывает интересующие RFC. Цитировать,

  

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

Answer 3

Первые изменения были выделены здесь .

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

  

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

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

Answer 4

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

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