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

Question

У меня есть веб-приложение, которое автоматически настраивает устройство. Связь осуществляется в режиме «запрос - ответ» с использованием HTTP. В настоящее время я использую поток для управления процедурой настройки, но обычно рекомендуется, чтобы потоки приложений не создавались на веб-серверах, поэтому мой вопрос заключается в том, должен ли я использовать механизм, основанный на событиях, а не поток? Используются ли рамки событий для поддержания состояния приложения или я думаю о них неправильно?

Если есть еще подходящие шаблоны проектирования, я бы хотел услышать о них.

Большое спасибо.

Answer 1

Я согласен с @Prashant, что попытка сравнить шаблон State-Machine с многопоточностью - это яблоки и апельсины. Как вы в настоящее время настраиваете устройство с помощью потока? Каковы долгосрочные требования для отслеживания состояния устройства и будет ли состояние устройства изменяться со временем?

Другими словами, является ли конфигурация усилием, выполняемым одним выстрелом, в котором было удобно отодвинуться в отдельный поток? Если вы заботитесь о переходах, особенно в течение относительно длительного периода времени, для ЦП, шаблон State-Machine - это инструмент, помогающий моделировать различные состояния и возможные переходы.

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

Я бы задал два вопроса:

1) Как вы смоделировали состояние вашего устройства?

2) Покупает ли поток что-то конкретное для настройки устройства?

Answer 2

Не уверен, что я полностью понимаю вашу ситуацию здесь, но в любом случае я буду иметь дело с ней.

Несколько лет назад я разработал приложение для обслуживания запросов активации ADSL для крупного оператора Telco.в моей стране.

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

Мы выбрали решение, основанное на «конечном автомате» своего рода.Каждый запрос был представлен (в БД Oracle) в виде записи заголовка, в которой суммировалось состояние (от «нового» до «выполнено» с различными промежуточными этапами) и серии дочерних записей, каждая из которых представляла собой один из необходимых N-этапов.чтобы завершить настройку.

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

Мы также запланировали «метапакет», который будет периодически проверять каждыйоткройте запись «заголовка», проверьте, все ли подключенные пошаговые записи были в «готовом» состоянии, и соответственно обновите статус заголовка.

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

Если бы мне пришлось работать над подобной проблемой сегодня, я бы предпочел подход на основе конечного автомата.