Что отличается между OSGi Service Tracker и Declarative Services

Я работаю над OSGi Service прямо сейчас, и у меня есть вопрос об использовании Сервисов в OSGi. Существует несколько способов регистрации службы пользователя. Может ли кто-нибудь объяснить разницу между OSGi Service tracker и Declarative Services? Какой из них лучше?

ОТВЕТЫ

Ответ 1

В OSGi ServiceTracker является программным способом получения ссылки на услугу. т.е. вы пишете код ServiceTracker, который "отслеживает" ссылку на другую службу и позволяет использовать ее, когда она станет доступной.

В отличие от Declarative Services (DS), вы можете объявлять зависимости, которые вставляются в ваш компонент. DS является, как таковой, формой инъекции зависимостей. График зависимости между службами вместе с порядком их начала будет определять, когда начнется ваш сервис. Свойство мощности в определении DS позволяет объявить, является ли отношение обязательным (1..1), множественным с наименьшим (1..n), необязательным (0..1) или множественным необязательным (0..n). Когда вы объявляете обязательные отношения, ваша служба не будет запускаться до тех пор, пока все зависимости не будут удовлетворены. Когда вы объявляете необязательные отношения, ваша служба запустится независимо от состояния зависимости, но вам нужно позаботиться о том, чтобы ссылка на вашу службу могла быть нулевой.

С практической точки зрения ServiceTracker представляет собой много шаблонов для написания и поддержки. Учитывая динамический характер сервисов OSGi, существует множество состояний, разрешенных спецификацией OSGi, которые необходимо учитывать. DS предоставит вам чистый способ объявить и поддерживать ваши зависимости. Четкие зависимости помогут вам поддерживать согласованность среды выполнения.

Ответ 2

Декларативные службы (DS) довольно просты в использовании, и вы избегаете некоторых шаблонов, связанных с использованием ServiceTracker. Если вы используете простой OSGI, используя только ServiceTracker, вам необходимо позаботиться о некоторых аспектах динамического характера служб OSGI. Сервисы могут приходить и уходить, и ваш компонент должен справиться с этим. Если вы используете DS, большая часть этой работы уже выполнена. Вам просто нужно определить ссылки на другие службы, и DS будет вводить эти ссылки, когда они станут доступными. DS будет активировать ваш компонент, когда будут выполнены требования к компоненту.

Если вы используете аннотации SCA Apache Felix или аннотации, предоставленные bndlib, вы также можете избежать написания xml, требуемого Declarative Services. Недавно группа OSGI также опубликовала свои аннотации. Я думаю, что те, которые предоставлены bndlib и те из OSGI, очень похожи, и я почти уверен, что инструмент bnd может обрабатывать оба.

Я использовал аннотации Apache SCR некоторое время назад, но теперь я предпочитаю использовать bndlib, потому что он включает аннотации для Metatype и некоторые классы, которые делают реализацию управляемой службы намного проще. Метатип - это спецификация, относящаяся к управляемым службам. В основном, он предоставляет метаданные, которые могут использоваться реализациями Config Admin для обеспечения более удобного для пользователя интерфейса для конфигурации компонента.

Я знаю две другие альтернативы: iPojo и Blueprint.

iPojo достаточно мощный и многофункциональный. Он абстрагирует большую часть содержимого OSGI и включает в себя некоторые интересные функции, такие как поддержка EventAdmin и поддержка ConfigAdmin.

Я использовал Blueprint немного, но из-за чрезмерного использования xml мне это не нравится. Я думаю, вы можете сказать, что Blueprint похож на Spring для OSGI.

Ответ 3

Служба OSGi Service Tracker позволяет зарегистрировать слушателей для определенных служб, поэтому вы можете реагировать, когда эта услуга станет доступной.

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