Положите динамический выбор сервиса OSGi в свою собственную службу?

Question

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

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

Кроме того, если у нас есть несколько служб лечения, которые хотят повторно использовать один и тот же сервисный таргетинг, в идеале алгоритм выбора должен быть реализован в его собственной службе. Назовем его SelectService и скажем, что он имеет логику для динамически идентифицирующих сервисов категорий «abc» и «xyz».

Я могу думать об этих основных альтернативах, чтобы пойти по этому поводу, может быть, их больше?

1. Пусть SelectService инспектировать развернутые услуги и потом как-то (как?) Набор свойств «ABC» и «АБВ» на них, когда это применимо. Затем службы лечения могут использовать стандарт ServiceTracker с фильтром свойств, чтобы найти нужные им услуги.

2. Пусть SelectService предлагают методы getAbcServices() и getXyzServices(), которые возвращают некоторые ServiceTracker -как объект. Услуги лечения могут вызывать эти методы для поиска целевых услуг.

3. Позвольте службам лечения объявить что-либо в реестре службы (служебный интерфейс или свойство услуги), чтобы выразить заинтересованность в выборе услуг. SelectService затем находит эти пожелания в стиле доски и уведомляет службы лечения о выборе.

4. Это неправильный способ думать в OSGi системе, и вы не должны даже хотеть сделать это :-)

---

EDIT 1:

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

targeted <--> extender 
service   service 

с добавлением, что служба расширитель разделяется на две части/слоев для повторного использования логики выбора:

targeted  extender   extender 
service <--> service <--> service 
       treatment ** selection 
       logic   logic 

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

---

[Meta: Возможно, было бы полезно разделить обсуждение на одну ответную нить (ответ + комментарии) на альтернативу?]

Answer 1

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

Например, чтобы реализовать с помощью декларативных Услуги:

@Reference(multiple = true, dynamic = true, optional = true) 
public void addFooService(Foo foo, Map<String, Object> serviceProps) { 
    // TODO: implement logic here to read serviceProps. Return early from 
    // this method if the service doesn't match your dynamic criteria. 
} 
public void removeFooService(Foo foo, Map<String, Object> serviceProps) { 
    // Be careful here, you will get services back that you didn't care about in the 
    // 'add' method. 
} 

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

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

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

Answer 2

Вы можете ознакомиться с прокси-сервисом. С помощью сервисных крючков OSGi вы можете выборочно скрывать службы и регистрировать прокси. Эта модель позволяет вам делать практически все, пока потребители этих услуг не забывают о том, что происходит.

soapbox { Это, в общем, я постараюсь, чтобы все было просто. Хотя многие из этих «расширений» выглядят невероятно полезными автором для некоторой простой работы, они со временем становятся узкими местами. Отсутствие обширной документации и, как правило, отсутствие необходимой функциональности с течением времени делает их PITA для будущих разработчиков.

Я видел так много систем, которые стали очень сложными не из-за их домена, а потому, что со временем слишком много разработчиков добавили свое собственное промежуточное программное обеспечение в попытке уменьшить свою собственную рабочую нагрузку, то есть самонастраиваемую сложность. Иногда немного избыточности легче понять/поддерживать. }