Служба OSGI против Singleton?

Я начинаю OSGI, и мне интересно, может ли кто-нибудь просветить меня о различии между созданием OSGI-сервиса и шаблоном singleton. Например, предположим, что у меня есть пакет core, который предоставляет IService, и несколько пакетов, которым необходимо получить доступ к этому. Я могу:

зарегистрировать службу в core -bundle, в которой плагины могут получить доступ к
предоставляет одноэлементный класс, предоставляющий услугу

Использование службы OSGI кажется довольно громоздким; и поскольку плагины должны в любом случае зависеть от Core (чтобы получить интерфейс), какое преимущество использования службы OSGI?

Ответ 1

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

Но здесь еще нужно рассмотреть вопрос о том, будет ли услуга громоздкой или нет. Черт, OSGi сам по себе может считаться громоздким. Может ли другой комплект обеспечить реализацию этого класса? Возможно, нет. Будет ли пакет Core закрыт или иначе не сможет обеспечить реализацию по требованию? Может быть.

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

Удачи.

Ответ 2

Службы - это соединения между независимыми модулями. Наличие модулей зависит от сервисов (с их пакетами спецификаций) может значительно уменьшить связь между модулями и, таким образом, обеспечить большую часть преимуществ модульности.

Я думаю, что одноэлементный шаблон используется двумя разными способами: вы просто хотите, чтобы один объект был разделен между набором пользователей (например, службой журнала), или у вас действительно может быть только один экземпляр (например, есть только одна часть аппаратное обеспечение). В общем, я вижу, что большинство людей в мире корпоративного программного обеспечения говорят о первом. Однако опыт показывает, что когда проекты растут, синглтоны становятся менее одиночными, но скорее общими объектами или, по крайней мере, являющимися общими объектами. Хорошая вещь в OSGi заключается в том, что вы можете моделировать как клиентов, так и клиентов "singleton", которые не обращают на это внимания, и не требуют какой-либо центральной конфигурации. Причина в том, что OSGi полагается на модули, ответственные за регистрацию, это локальное решение при прослушивании службы.

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

Наконец, службы OSGi не громоздки, не так как у нас есть DS с аннотациями. Регистрация службы теперь намного проще, чем создание Spring bean, без xml, без центральной конфигурации:

// A component registered as a ISingleton service
@Component
public class MyImpl implements ISingleton {
  void doSingle() { ... }
}

// A component that uses the ISingleton component
@Component
public class MyConsumer {

  @Reference
  void setISingleton(ISingleton is) { ... }
}

... И динамика приходит в основном бесплатно...

Ответ 3

My Модель Threading Model OSGi, в которой я полагаю, что каждая услуга является однопользовательской для потребителя услуг. Поскольку только один объект службы зарегистрирован в реестре служб osgi. (но вы также можете переопределить это поведение). Итак, что касается программирования, то поведение одноэлементного класса и службы OSGi одинаково. Переменные уровня вашего класса разделяются между различными вызовами пользователей службы.

Я скажу, что OSGI Service - Singleton ++

Но есть и различия. OSGi предоставляет вам отдельный класс-загрузчик для каждой службы, что невозможно в одноэлементном режиме. Все классы {singleton} загружаются одним загрузчиком классов. Мы не можем иметь два класса с одним и тем же именем (полное имя) в одноэлементном, но это возможно в OSGi.

В некоторых ситуациях мы должны подтвердить, что класс должен быть загружен только один раз (создание сеанса hibernate factory, инициализация службы hdfc, создания POJO, которые являются тяжелыми инициализациями, требуемыми только один раз). Теперь, если вы живете в сценарии Java EE, несколько раз ваш однопользовательский класс загружается дважды двумя разными загрузчиками классов. Таким образом, это приводит к двукратному выполнению статического блока; ненужная работа. Такие проблемы с загрузчиком классов легко обрабатываются OSGi (так как вы новичок, я чувствую, что загрузка класса является проблемой для вас в ближайшие несколько дней).

Еще одна отличная функция, предоставляемая OSGi, - это обновление пакета. Подумайте, вы изменили код в своем одиночном классе. Теперь вам нужно развернуть этот обновленный класс в запущенном приложении. Вам необходимо перезагрузить систему, чтобы каждый загрузчик классов oneton обновлял новый экземпляр singleton. Это не требуется в OSGi, просто обновите комплект.

Я скажу, если вы собираетесь разрабатывать более крупные приложения (корпоративный масштаб), или если вам нужно разработать код для ограниченной аппаратной емкости (низкие ограничения памяти, низкая вычислительная мощность), то перейдите на OSGi, это лучше для крайних концов. Для всех остальных нормальное java-кодирование будет работать отлично.

Ответ 4

Вы можете управлять жизненным циклом (развертывать новую версию службы, одновременно запускать несколько версий и т.д.) службы, но вы не можете управлять жизненным циклом однопользовательского режима без перезапуска JVM (даже при перезапуске у вас может быть только 1 версия доступна в любой момент времени).