Ответ 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 будет сразу понятна.