Когда использовать ServiceLoader над чем-то вроде OSGi

Question

Будучи человеком, страдающим аллергией на зависимости, когда бы я использовал что-то вроде OSGi вместо встроенного Java 6 http://java.sun.com/javase/6/docs/api/java/util/ServiceLoader.html (я хочу, чтобы файлы плагинов просто вставлялись).

(к вашему сведению, это приложение для Scala, открытое для любых предложений, ServiceLoader чертовски близко к тому, что я хочу).

Answer 1

Если ServiceLoader в основном соответствует вашим потребностям, это говорит о том, что вы ищете обнаружение службы посредством наличия файлов в пути к классам. Это лишь малая часть того, что предоставляет OSGi.

OSGi позволит вам динамически устанавливать пакеты, рекламировать сервисы, отзывать рекламные объявления и удалять пакеты во время работы приложения. Кроме того, как потребитель услуг вы можете с нетерпением искать их - с помощью фильтрации предикатных запросов - и определять, когда поставщики предлагаемых услуг приходят и уходят. Эти пакеты не должны лежать на пути к классам, и они могут быть представлены в различных формах; Я вспоминаю файлы Jar и «взорванные каталоги».

В отличие от этого, ServiceLoader делает только одно: обнаруживает обнаруживаемые фабрики. Обычно вы создаете интерфейс в заводском стиле, который принимает некоторый аргумент, чтобы решить, может ли этот провайдер предложить соответствующую услугу, такую ​​как сопоставление заданного имени набора символов с CharsetDecoder. Там нет формализованного протокола для приобретения и выпуска услуги от такого провайдера. OSGi формализует привязку потребителей к услугам. Потребитель может получать уведомления, когда новые поставщики подключаются к сети, и поставщик может получать уведомления, когда потребитель приобретает и выпускает экземпляр службы. Если этот контроль жизненного цикла важен для вашего сервиса и вы отказываетесь от OSGi, вам придется создать его самостоятельно; ServiceLoader не заходит так далеко.

Альтернативно, вместо того, чтобы искать и использовать сервис, вы можете использовать более пассивный декларативный подход и позволить одному из менеджеров зависимостей OSGi сопоставить ваши заявленные потребности с доступными поставщиками услуг. Есть много менеджеров зависимостей на выбор. пружинные динамические модули - один из самых способных.

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

Answer 2

Как указывает seh, если вас интересует только простое обнаружение сервисов, ServiceLoader - это легкий способ отделить потребителей от поставщиков. Но он не предлагает никакой помощи в создании сервисов вместе.

Например, предположим, что службе A необходимо использовать службу B. Это «зависимость от службы» ... но что делать A, если B недоступен? В OSGi мы можем организовать, что если B недоступен, то и A не будет - при условии, что зависимость является обязательной; мы также можем поддерживать необязательные зависимости. С другой стороны, при использовании ServiceLoader служба A не контролирует свою доступность, пока JAR, в котором она находится, находится на пути к классам ... поэтому она должна обеспечивать свою функциональность даже в отсутствие требуемых "серверных" служб.

Еще одна вещь, которую следует иметь в виду при использовании ServiceLoader, - попытаться абстрагировать механизм поиска. Механизм публикации довольно приятный, чистый и декларативный. Но поиск (через java.util.ServiceLoader) так же безобразен, как ад, реализован как сканер пути к классам, который ужасно ломается, если вы помещаете код в любую среду (такую ​​как OSGi или Java EE), которая не имеет глобальной видимости. Если ваш код запутался с этим, вам будет сложно запустить его на OSGi позже. Лучше написать абстракцию, которую можно заменить, когда придет время.