Почему я должен предпочесть OSGi Services экспортируемым пакетам?

Question

Я пытаюсь разобраться с OSGi Services. Основной вопрос, который я постоянно задаю себе: в чем преимущество использования сервисов вместо работы с пакетами и их экспортированными пакетами?

Насколько мне известно, концепция Late Binding как-то связана с этим. Зависимости пакета связываются вместе при запуске пакета, так что, я думаю, они довольно исправлены. Но с услугами это, кажется, почти то же самое. Пакет запускает и регистрирует сервисы или связывается с сервисами. Конечно, службы могут приходить и уходить когда угодно, и вы должны отслеживать эти шансы. Но основная идея не кажется мне другой.

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

В другом тексте я прочитал, что недостатком использования экспортируемых пакетов является то, что они делают приложение более хрупким, чем сервисы. Автор написал, что если вы удалите один пакет из графа зависимостей, другие зависимости больше не будут встречаться, что может вызвать эффект домино на всем графе. Но не может ли то же самое случиться, если служба отключится? Мне кажется, что сервисные зависимости не лучше, чем пакетные.

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

Подводя итог моим вопросам:

Каковы основные преимущества использования OSGi Services, которые делают их более выгодными, чем экспорт и импорт пакетов?

---

Добавление

Я попытался собрать дополнительную информацию об этой проблеме и найти какое-то сравнение между простым экспортом / импортом пакетов и сервисов. Может быть, это поможет нам найти удовлетворительный ответ.

1. Start / Stop / Update

   Как пакеты, так и пакеты, и службы могут быть запущены и остановлены. В дополнение к этому они могут быть отчасти обновлены. Сервисы также связаны с самим жизненным циклом пакета. Но в данном случае я имею в виду, можно ли запускать и останавливать службы или пакеты (чтобы экспортированные пакеты «исчезали»).

2. Отслеживание изменений

   ServiceTracker и BundleTracker позволяют отслеживать и реагировать на изменения в доступности пакетов и услуг.

3. Конкретные зависимости от других пакетов или услуг.

   Если вы хотите использовать экспортированный пакет, вы должны импортировать его.

   Import-Package: net.jens.helloworld
   

   Будет ли net.jens.helloworld предоставлять услугу, мне также потребуется импортировать пакет для получения интерфейса.

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

4. Возможность иметь более одной реализации

   Конкретные пакеты могут быть экспортированы несколькими пакетами. Может существовать пакет net.jens.twitterclient , который экспортируется из пакета A и пакета B. То же самое относится и к услугам. Интерфейс net.jens.twitterclient.TwitterService может быть опубликован пакетами A и B.

Подводя итог, короткое сравнение (экспортируемые пакеты / услуги):

1. ДА / ДА
2. ДА / ДА
3. ДА / ДА
4. ДА / ДА

Так что разницы нет.

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

альтернативный текст http://img688.imageshack.us/img688/4421/bundleservicecomparison.png

Итак, если нет реальной разницы между экспортируемыми пакетами и сервисами, в чем преимущество использования сервисов?

Мое объяснение:

Использование услуг кажется более сложным. Но сами услуги кажутся более легкими. Должна быть разница (с точки зрения производительности и ресурсов), если вы запускаете / останавливаете весь пакет или просто запускаете и останавливаете конкретную службу.

С архитектурной точки зрения я также предполагаю, что пакеты можно рассматривать как основу приложения. Фонд не должен часто меняться с точки зрения запуска и остановки пакетов. Функциональность обеспечивается службами этих пакетов в некотором динамическом слое над «слоем пакета». Этот «уровень обслуживания» может подвергаться частым изменениям. Например, служба запросов к базе данных не регистрируется, если база данных отключается.

---

Каково ваше мнение? Я начинаю получать весь смысл услуг или я все еще думаю, что неправильно? Есть ли что-то, чего мне не хватает, что сделало бы услуги более привлекательными по сравнению с экспортируемыми пакетами?

Answer 1

Все довольно просто: пакеты просто предоставляют классов , которые вы можете использовать.Используя Импорт / Экспорт, вы можете защитить видимость и избежать (например) конфликтов версий.Сервисы - это экземпляры классов , которые удовлетворяют определенному договору (интерфейсам).

Таким образом, при использовании Сервисов вам не нужно заботиться ни о происхождении реализации, ни о деталях реализации.Они могут даже измениться, когда вы используете определенный сервис.

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

Это не только OSGi - просто хорошая практика.

В мирах, отличных от OSGi, вы можете использовать каркас Dependency Injection (DI), такой как Guice, Spring или аналогичный.OSGi имеет сервисный уровень, встроенный в фреймворк, и позволяет фреймворкам более высокого уровня (Spring, Guice) использовать этот уровень.- так что, в конце концов, вы обычно не используете OSGi Service API напрямую, а адаптеры DI из удобных для пользователя сред (Spring -> Spring DM, Guice -> Peaberry и т. д.).

HTH, Toni

Answer 2

Я бы порекомендовал приобрести эту книгу. Он отлично справляется с объяснением сервисов и анализирует создание нетривиального приложения, которое использует OSGi Services.

http://equinoxosgi.org/

Моя компания регулярно создает более 100 комплектных приложений с использованием сервисов. Основные преимущества, которые мы получаем от использования услуг:

1) Слабая связь реализации производителя / потребителя

2) Поставщики услуг горячей замены

3) Более чистая прикладная архитектура

Answer 3

Когда вы начинаете с OSGi, всегда легче начать с подхода экспорта пакета, он, конечно, кажется более похожим на java. Но когда ваше приложение начинает расти, и вам требуется немного динамичности , сервисы - путь.

Export-package выполняет только разрешение при запуске, тогда как службы - это постоянное разрешение (которое вы можете захотеть или нет). С точки зрения поддержки, наличие услуг может быть очень страшным (это детерминистично? Как я могу воспроизвести проблемы?), Но это также очень мощно.

Питер Криенс объясняет, почему он считает, что Услуги - это смена парадигмы так же, как и в свое время ОО. см. µServices и клейкая лента .

За весь мой опыт работы с OSGi у меня еще не было возможности реализовывать сложные сервисы (то есть более одного уровня), и, конечно, аннотации кажутся подходящими. Вы также можете использовать динамический модуль Spring для облегчения работы с сервисными трекерами. (и многие другие параметры, такие как iPOJO и Blueprint )

Answer 4

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

Пакету, использующему службу, не нужно ничего знать о том, как инициализируется служба.

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

Answer 5

Рассмотрим два следующих сценария:

1. Пакет A предлагает услугу, которая является арифметическим дополнением add(x,y) return x+y. Для этого он экспортирует «пакет mathOpe» с «интерфейсом IAddition» и регистрирует сервис в реестре сервисов. Пакеты B, C, D, ... используют эту услугу.

2. Bundle A экспортирует «пакет mathOpe», где мы нашли класс Addition, выставляющий операцию (x+y)<--add(x,y). Пакеты B, C, D, ... импортировать пакет mathOpe.

Сравнение сценария 1 со сценарием 2:

• Всего один экземпляр реализации против множества экземпляров (не стесняйтесь сделать его статичным!)
• Динамическое управление службами: запуск, остановка, обновление и отсутствие управления, потребитель владеет реализацией («служба»)
• Гибкий (мы можем представить себе удаленный сервис по сети) против негибкого

... среди прочих.

PS: я не эксперт OSGI и не Java, этот ответ показывает только мое понимание феноменов:)

Answer 6

Я думаю, что эта превосходная статья может ответить на многие ваши вопросы: OSGi и как это произошло .