Когда использовать ServiceLoader по чему-то как OSGi
Быть кем-то, у кого аллергия на зависимости, когда был бы, я использую что-то как OSGi вместо созданного в java 6 http://java.sun.com/javase/6/docs/api/java/util/ServiceLoader.html (я хочу позволить сменным банкам просто заглядываться).
(К вашему сведению это находится в scala приложении, открытом для любых предложений, ServiceLoader является довольно проклятым близко к тому, что я хочу).
2 ответа
Если ServiceLoader в основном соответствует вашим потребностям, это говорит о том, что вы ищете возможность обнаружения сервиса через наличие файлов на пути класса. Это только малая часть того, что обеспечивает OSGi.
OSGi позволит вам динамически устанавливать пакеты, рекламировать сервисы, отзывать рекламу, и удалять пакеты все это во время работы приложения. Более того, как потребитель услуг, вы можете искать их с нетерпением - с фильтрацией предикатных запросов - и определять, когда предлагаемые поставщики услуг приходят и уходят. Эти пакеты не обязательно должны лежать на пути класса, и они могут быть предоставлены в различных формах; Jar-файлы и "взломанные каталоги" являются двумя, как я помню.
Напротив, ServiceLoader делает только одно: раскрывает открытые фабрики. Обычно вы создаёте интерфейс в стиле фабрики, который принимает решение о том, может ли этот провайдер предлагать соответствующую услугу, например, отображение заданного имени набора символов на CharsetDecoder. Формализованного протокола для получения и освобождения услуги от такого провайдера не существует. OSGi формализует привязку и снятие привязки потребителей к услугам. Потребитель может получать уведомления, когда новые провайдеры появляются в сети, а провайдер может получать уведомления, когда потребитель приобретает и выпускает экземпляр услуги. Если этот контроль жизненного цикла важен для вашего сервиса, и вы отказываетесь от OSGi, вам придется построить его самостоятельно; ServiceLoader не заходит так далеко.
Вместо того, чтобы жадно искать и использовать сервис, вы можете принять более пассивный, декларативный подход и позволить одному из менеджеров зависимости от OSGi сопоставить заявленные вами потребности с доступными провайдерами сервисов. Существует множество менеджеров зависимостей на выбор. Весенние динамические модули являются одними из самых эффективных.
OSGi предоставляет множество других "промежуточных" возможностей. Я не буду пытаться продать их вам здесь, так как ваш вопрос в основном сосредоточен на том, что бы вы упустили, выбрав ServiceLoader.
Как указывает seh, если вас интересует только простое обнаружение служб, то ServiceLoader - это легкий способ отделить потребителей от провайдеры. Но он не предлагает никакой помощи в составлении сервисов вместе.
Например, предположим, что сервис A должен использовать сервис B. Это «зависимость сервиса» ... но что делать A, если B недоступен? В OSGi мы можем сделать так, чтобы если B недоступен, то и A не будет - при условии, что зависимость является обязательной; мы также можем поддерживать необязательные зависимости. С другой стороны, при использовании ServiceLoader служба A не контролирует свою доступность, пока JAR, включающий ее, находится в пути к классам ... поэтому он должен обеспечивать свою функциональность даже при отсутствии требуемых «серверных» служб.
Еще одна вещь, о которой следует помнить при использовании ServiceLoader, - это попытаться абстрагироваться от механизма поиска. Механизм публикации довольно приятный, чистый и декларативный. Но поиск (через java.util.ServiceLoader) чертовски уродлив, реализован как сканер путей к классам, который ужасно ломается, если вы помещаете код в любую среду (например, OSGi или Java EE), которая не имеет глобальной видимости. Если ваш код запутается в этом, вам будет трудно позже запустить его на OSGi. Лучше написать абстракцию, которую можно заменить, когда придет время.