преимущества заключаются в разделении частей вашего приложения. После того как вы настроили шину и добавили приложения, вы можете легко расширить свое приложение, добавив новые элементы, которые, как вы можете гарантировать, не затронут другие части. Это очень хороший способ постоянного добавления в систему с течением времени.
например. У нас есть система, подобная этой, каждая команда реализована как часть общего графического интерфейса пользователя. Если мы хотим добавить новую функцию или изменить существующую, мы просто пишем новую часть и добавляем ее в систему. Когда он вызывается, он не зависит от остальных. Это означает, что мы можем очень легко расширить наше приложение. Кроме того, у нас есть сообщение, передаваемое между узлами в нашей сети - когда что-то изменяется на 1 компьютере, сообщение отправляется всем остальным, чтобы они могли обновиться. У нас есть сотни разных сообщений для разных событий, поэтому мы можем расширить систему, добавив новую службу, которая реагирует на соответствующие сообщения.
Архитектура передачи сообщений обычно имеет те же функции, что и веб-службы, у вас есть отдельные службы, к которым вы можете обращаться, и вы можете легко добавлять новые.
Не думайте, что архитектурам передачи сообщений требуются причудливые (и дорогостоящие!) Продукты промежуточного программного обеспечения, хотя Windows работает на архитектуре передачи сообщений - каждое сообщение WM_ *, передаваемое окну, является ... ну, сообщение, и я думаю, что показывает лучший пример архитектуры - ни одна часть системы не должна знать ни о какой другой части, вы можете расширять ее бесконечно, поскольку вы можете обрабатывать столько элементов управления, сколько вам нужно в любом диалоговом окне и т. д. и т. д.
Передача сообщений - это потрясающая архитектура, хотя она может быть медленнее, чем тесное соединение вашего приложения, и это не является большой причиной, чтобы не использовать ее в настоящее время, особенно если вы уже используете сценарии или приложения .net.