Как разумно выбирать во время выполнения среди нескольких сервисов OSGi? - PullRequest
Новая
       26

Как разумно выбирать во время выполнения среди нескольких сервисов OSGi?

7 голосов
/ 27 апреля 2011

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

while(stopCriterion){
    operator.doSomething(); //There exist many operator implementations
}

Мой первый подход - использовать DS для предоставления сервисов и связывания сервисов.с 0..n и динамической политикой.Затем из внешнего интеллектуального компонента уведомите алгоритм, который служба использует в каждой итерации (возможно, используя EventAdmin ).

operator[selected].doSomething();

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

ОднакоЯ не знаю, является ли это хорошей идеей или существует другой лучший механизм для динамического выбора, какую реализацию использовать.Я думаю, что использование ServiceTracker вместо DS не является хорошим вариантом, но я открыт для предложений:)

Заранее спасибо.

Ответы [ 2 ]

5 голосов
/ 27 апреля 2011

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

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

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

0 голосов
/ 27 апреля 2011

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

Грубая реализация может выглядеть так: 

public Worker {
  private Operator operator;    // your actual operator strategy
  public void setOperator(Operator actualOperator) {
    this.operator = operator;
  }

  public doSomething() {

     while(stopCriterion) {
       Operator operatorForThisIteration = operator;  // pick the injected service
       operatorForThisIteration.doSomething;
     }
  }
}

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

...