Здравствуйте, Sharov, Вы писали:

C>>2) Прямые вызовы одного сервиса другого сосут меньше, но при любом неловком движении можно получить динамически нестабильную систему.
C>>3) Системы на сообщениях сосут необыкновенно. Их надо избегать настолько, насколько вообще возможно.
S>Можно более подробные обоснования?
Во-первых, на системах сообщений совершенно нельзя делать протоколы вида вопрос-ответ. Любые попытки такого приведут в АДЪ из-за сложности.

Во-вторых, системы сообщений могут быть динамически нестабильны. Представим, что обработка требует 3 шагов: А, Б, В. Шаг А добавляет сообщение в очередь шага Б, который обрабатывает их и добавляет их в очередь В.

Если по каким-то причинам шаг Б начинает тормозить, то мы можем получить ряд интересных вариантов развития событий. Очередь начнёт расти неограниченно, при этом в зависимости от политики очереди новые сообщения могут вообще не обработаться (если FIFO и есть таймаут).

В-третьих, вопрос надёжности — если сообщение из очереди ошибочно удалено, то очень сложно разобраться что там вообще произошло.

В-четвёртых, появляется шаблон отказа — "отравленное сообщение". 1. При обработке сообщения случается ошибка и система его кладёт обратно в очередь. Далее goto 1. Если таких сообщений несколько десятков, то они спокойно забивают остальной трафик.

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