пятница, 25 сентября 2009 г.

Вышла новая спецификация OSGi 4.2


Недавно OSGi Alliance выпустил версию 4.2 спецификации OSGi. Некоторые реализации уже частично совместимы с данной версией, например Equinox 3.5 и Apache Felix 2.0. Поэтому, я думаю, сейчас самое время рассмотреть, что нового нам предлагают.


Framework launching - появилась спецификация, описывающая прозрачные и, главное - одинаковые, механизмы запуска OSGi-фрэймворка независимо от используемой реализации. Теперь можно тестировать работу разрабатываемого приложения на различных OSGi-движках (Equinox и Apache Felix), просто заменяя соответствующий JAR.

Remote Services - удаленные сервисы, ранее известные как Distributed OSGi и RFC 119. Фактически, это новое название для технологии, позволяющей взаимодействовать OSGi-фреймворкам, запущенным на разных JVM. Суть взаимодействия заключается в том, что сервисы, предоставляемые одним экземпляром фреймворка, доступны клиентам, работающих на другом экземпляре фреймворка. Тем самым мы получаем объединенные преимущества распределенной обработки и динамической OSGi-шины.

Blueprint Service. Те, кто привык работать со спринговским IoC-контейнером, увидят непосредственное сходство с Blueprint-сервисом. Он позволяет клиентам определять во внешнем конфигурационном файле с какими сервисами они связаны и динамически разрешать эти зависимости. Как и при использовании декларативных сервисов, вы можете накладывать ограничения на типы сервисов и их параметры. Отличие заключается в том, что Blueprint Service может предоставлять прокси в случае недоступности сервиса (например, если соответствующий бандл еще не запущен). При попытке клиентского кода осуществить взаимодействие с сервисом, этот код блокируется до тех пор, пока сервис не станет доступен. Так же использование Blueprint Service позволяет избежать написания контейнеро-зависимого кода, что особенно важно при разработке приложения, работающего как с OSGi, так и без OSGi.

Bundle Tracker. OSGi уже давно содержит Service Tracker, позволяющий относительно безопасно взаимодействовать с сервисами. Bundle Tracker - это расширение, позволяющее отслеживать бандлы. BundleTracker предоставляет ту же функциональность для BundleListener, что и ServiceTracker - для ServiceListener. Он может использоваться для обеспечения динамической регистрации ресурсов, определенных в бандлах. Например, можно автоматически искать web.xml во всех новоподключяемых бандлах и регистрировать описанные сервлеты через HttpService.

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

Conditional permissions - условные права. В OSGi 4.2 произошло расширение набора прав доступа, появился доступ DENY. Так же имеется механизм работы с сертификатами подписей, что позволяет определять возможные операции для подмножества бандлов. Все это помогает создавать защищенные OSGi-платформы, в которых неподписанные бандлы просто будут заблокированны.

Так же добавились менее значимые возможности, такие как свой MIME-тип для бандлов (application/vnd.osgi.bundle), возможность определять Bundle-Icon и Bundle-License и расширение XML-схемы описания декларативных сервисов.

Источник: OSGi 4.2 released, скачать спецификацию можно здесь.

А что вы думаете о новой спецификации?

Понравилось сообщение - подпишитесь на блог или читайте меня в twitter

2 комментария:

Unknown комментирует...

сравниваю новую спецификацию с самой первой и становится жутковато )) все новые и новые, безусловно полезные, возможности делают osgi монстриком, который скоро вырастет в неперевариваемого монстра...
впрочем... это не недостаток новой спецификации, а скорее неизбежный процесс развития любой перспективной компьютерной технологии...

Unknown комментирует...

Да, согласен. С одной стороны - все растет, а с другой стороны спецификация - это лишь средство обеспечить некий стандарт.

Я думаю, в основном изменения приходят от разработчиков шин (от тех же Eclipse и Apache), а затем стандартизируются ради совместимости.

Отправить комментарий

Любой Ваш комментарий важен для меня, однако, помните, что действует предмодерация. Давайте уважать друг друга!