Попробуем решить, какие события в распределенной системе могут быть и какие реакции должны после этого последовать.
Изначально, система, строится как распределеннная, в которой нет главного модуля.
Построение таких систем всегда было более сложной, чем системы, с выделенным мастером. Но мы попробуем. Для этого надо составить работу алгоритма, обаботки событий в системе.
Система обработки событий будет похожа на работу обычного GUI приложения.
Введем понятия:
Событие: обьект, обладающий рядом свойств. Некоторые свойства, будут стандартные (наследование от интерфейса событие), некоторые будут уникальными.
Свойства события: тип события, источник, Без этих свойств просто никуда. В некоторых случаях, этого даже будет достаточно для обработки простых действий. Например обработка работы простых дискретных датчиков.
"
Тип события: Сработка,
Источник: ДатчикДвиженияХолл
".
Для датчиков посложнее, надо добавить еще одно поле "значение" тут уже имеем достаточно большое поле для разных сценариев.
Пример:
"
Тип события: статус,
Источник: ДатчикОткрытияОкнаСпальня1_1,
Значение: (Открыт, Закрыт, Обрыв)
"
или
"
Тип события: статус,
Источник: tУлица,
Значение: -10.12
"
Подходим к типам событий в системе:
Типы событий можно условно разделить на две группы: простые события, составные события.
Простые события типа: сработка, статус, изменение статуса, генерируют простые датчики. На основе обработки этих событий мудули могут генерировать более сложные события для дальнейшей работы системы в целом.
Составные события, называются так не потому, что содержат в себе больше данных чем простые, а потому, что генерация этих событий происходит в системе на основании нескольких параметров, и рождает такое событие несколько событий, пришедших извне.
Например, событие о включении-выключении того, или иного освещения в доме зачастую составное событие.
Вот примерный алгоритм включения света в туалете:
1) если пришло событие "от: ДатчикДвериТуалет, Значение: Открыт"
2) если статус "что: СветВТуалете , Значение: Выключен"
3) то изменить статус "что: СветВТуалете, Значение: МедленноВключить"
Где, процедура изменения статуса, собственно и сгенерирует событие
"
Тип события: статус,
Источник: Умка1,
Назначение: СветВТуалете
Значение: МедленноВключить
"
Можно заметить, что у нас добавилось новое свойство события "Назначение". Когда мы точно знаем, кому это событие обрабатывать, то мы может сразу указать получателя.
Это заметно сократит размеры кода. Т.к. некоторые обьекты вообще не будут слушать все события, а будут слушать только события предназначенные для них самих.
Составные события в свою очередь могут в дальнейшем разбиваться на несколько простых. Для примера возьмем работу системы отопления.
Работа погодозависимого управления отоплением зависит от множества параметров, как то: t в доме, t на улице, скорость ветра, возможно даже влажность (хотя я пока не знаю как она может влиять).
Сами датчики, генерят события (скажем раз в N секунд)
"
Тип события: статус,
Источник: tУлица,
Значение: -13.2
"
"
Тип события: статус,
Источник: tСпальня,
Значение: 22.3
"
"
Тип события: статус,
Источник: tГостинная,
Значение: 21.9
"
Далее, обслуживающая умка собирает статистику и создает событие
"
Тип события: статус,
Источник: dtУлица,
Значение: -3.1
"
"
Тип события: статус,
Источник: dtГостинная,
Значение: -1.2
"
событие dt это уже составное событие. На основе обработки значений dt мы генерируем новое событие:
"
Тип события: статус,
Источник: Умка1,
Назначение: dtОтопление,
Значение: 1
"
Мы генерируем событие для отопления, чтоб они подняли температуру на 1 градус.
Это событие уже в зависимости от логики работы котельной создась кучу событий:
"
Тип события: статус,
Источник: Умка2,
Назначение: Горелка,
Значение: вкл
"
"
Тип события: статус,
Источник: Умка2,
Назначение: Насос1,
Значение: вкл
"
"
Тип события: статус,
Источник: Умка2,
Назначение: Насос2,
Значение: вкл
"
По мере программирования, системы может получиться так, что алгоритмы некоторых модулей будут очень большими. Основываясь на системе событий, мы может часть математики переносить на другие модули освобождая память и процессорное время на загруженных.
Все события, произошедшие непосредственно на датчиках самого модуля должны иметь адрес назначения, собственно этот модуль. И уже сам алгоритм обработки в модуле должен принимать решение, что делать дальше.
При таком подходе, мы можем очень гибко настраивать всю систему. Начиная от простейшей "Мастер-Слэйв" до полноценной распределенной системы.
На первом этапе вообще можно попросить всех Умок, просто транслировать все события в сеть, а на компьютере сделать обработчик всех событий. В дальнейшем готовые алгоритмы перенести на модули, которые больше всего для этого подходят.