Хорошие практики для привязки услуг OSGi в кардинальности 0..n?

Допустим, у меня есть пакет, который хочет передать информацию всем своим слушателям. Учитывая, что я использую декларативные службы, в которых MyComponent потребляет 0..n ComponentListeners, у меня будет что-то вроде этого:

public class MyComponent {

    private List<ComponentListener> listeners;
    private String data;

    public MyComponent() {
        listeners = new ArrayList<>();
    }

    // Someone else will call this
    public void updateData(String newData) {
        data = newData;
        notifyAll(data);
    }

    // Broadcasts the data to all listeners
    private void notifyAll(String data) {
        for (ComponentListener listener : listeners) {
            listener.updateData(data);
        }
    }

    // Declarative Service binding methods
    public void bindComponentListener(ComponentListener cl) {
        listeners.add(cl);
    }

    public void unbindComponentListener(ComponentListener cl) {
        listeners.remove(cl);
    }
}

Мои вопросы:

  1. Рекомендуется ли кардинальность 0..n? Единственный пример, который я нашел, был взят из учебника по Apache Felix, аналогичный приведенному выше.
  2. Считается ли подход наблюдатель/наблюдаемый хорошей практикой в ​​OSGi?
  3. Если я хочу уведомить всех слушателей, я должен вызывать listener.updateData(data); в разных потоках для каждого слушателя, верно? Таким образом, я гарантирую, что все слушатели будут уведомлены одновременно.

person Fapaz    schedule 04.09.2014    source источник


Ответы (2)


Если вашей основной целью является широковещательная передача информации, вы также можете использовать администратор событий OSGi, у felix есть краткое руководство. Обработка ваших собственных слушателей через Сервисы может быть считаться вредной.

person apf7188    schedule 04.09.2014
comment
Я совершенно забыл об администраторе событий, но прежде чем пытаться что-то с этим сделать, я сначала прочитаю статью полностью. Благодарю вас! - person Fapaz; 05.09.2014

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

person Christian Schneider    schedule 04.09.2014
comment
Также показанный код не является потокобезопасным, но, возможно, вы пропустили это для простоты примера в этом вопросе. Даже использование нескольких потоков не гарантирует одновременного уведомления всех слушателей. - person BJ Hargrave; 04.09.2014
comment
Да, я думал о реализации пула потоков, чтобы ограничить нагрузку, потому что я не знал, сколько слушателей получит уведомление. На самом деле, я просто хочу избежать слушателя, которому потребуется много времени для обработки уведомления, так как это задержит других слушателей. Однако, как упоминал apf7188, было бы неплохо использовать администратора событий, не так ли? - person Fapaz; 05.09.2014
comment
Преимущество администратора событий в том, что вам не нужно управлять слушателями. Плохо то, что администратор события отправляет пары ключ-значение. Таким образом, интерфейс выглядит менее объектно-ориентированным. - person Christian Schneider; 05.09.2014