Взаимодействие между модулями (одной проги) сообщениями?

[Артем]

Добрый день/вечер!

Есть идея написать прогу, которая будет состоять из модулей
(набора исполняемых файлов, exe , dll) взаимодействие между модулями осуществляется ТОЛЬКО посредством сообщений. Получается что каждый модуль НИЧЕГО не знает о других, просто
получает сообщения и, если может, обрабатывает их и посылает
свои сообщения...
 
Такая концепция обещает много всего "шоколадного" , но где-то в глубине души у меня появились сомнения в том что такое можно реализовать  : между модулями надо передовать большие массивы данных, что делать если вдруг одно сообщение захотят обработать два модуля, как доставлять сообщения до каждого модуля  и т.д.


Где бы можно было почитать про подобные концепции, или может кто-то уже пытался что-то такое сделать?
Я не думаю что эта идея новаторская.

Буду благодарен за любые комментарии

 P.S. Чуть не забыл: все это хозяйство будет работать на одном компе, и под win2000/XP. НО возможно (в далеком будущем) придеться переносить под ЛИНУХ

[Серж]

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

[npak]

Артем, возможны различные архитектурные решения.

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

Для организации передачи данных есть масса возможностей.

Можно воспользоваться средствами удалённого вызова методов объектов -- CORBA, COM/DCOM, JRMI, Web services, RPC (в некоторой степени).  Можно написать свою инфраструктуру удалённого вызова, например поверх сокетов.

Можно построить архитектуру на очередях -- компонент читает из некоторой очереди запрос (или из нескольких очередей) и ставит результаты обработки в соответствующие очереди.  Для очередей событий можно взять существующие решения, типа Microsoft Message Queues или коммерческих систем (свободных я не знаю), можно написать самому на базе MPI или сокетов.

Можно сделать обмен информацией через базу данных.

Короче, возможностей море.  Выбор за тобой.

[Серж]

npak, а зачем городить все это на одном компьютере, хотя и можно.

[npak]

Серж, с одной стороны, никто не говорил про один компьютер.

Во-вторых, даже на одном компьютере компоненты могут работать в разных адресных пространствах (разных процессах) прямой функциональный вызов невозможен.

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

В-четвёртых, событийная архитектура имеет свои плюсы в многопоточном приложении.  Активные объекты (т.е. объекты, у которых есть метод со своим потоком управления) могут построить асинхронное взаимодействие на сообщениях.

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

[Артем]

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

 В том то и дело, что хотелось бы, что бы они общались "беспорядочно". И если какому-то модулю нужны результата работы другого--пусть ждет нужного сообщения.

А если завести управляющий модуль--то как минимум нужно  делать так, что бы этот модуль имел информацию обо всех модулях.

 В идеале хотелось бы, что бы добавление нового модуля заключалось, лишь, например, в добавлении ddl-ки в папку проекта и перезапуска (НЕ ПЕРЕКОМПИЛЯЦИИ!) приложнения.

[Артем]

npak, спасибо за идею об очередях . Как ни странно, я упустил ее из своего рассмотрения:shock:

 "центральный сервер"--это объект который диспетчеризацией сообщений, или что другое?

Кстати, Серж, а есть ли какая то альтернатива COM-технологии для одной машины? Тут мой коллега активно предлагает вариант на Com объектах, а я нутром чую что можно сделать проще (и может быть лучше ), но вот привести какой-то законченный вариант пока не могу

[Серж]

Артем, в любом случае, проще всего иметь выделенный сервис доставки сообщений, который в конечном счете будет хранить необходимую информацию о модулях (по мере поступления сообщений) и действительно, как писал npak, его проще всего реализовать с помощью базы данных, где уже решены проблемы синхронизации. Пример, конечно, Microsoft Message Queues на базе MS  SQL Server, но можно слепить и что-нибудь более простое буквально из 2-х - 3-х таблиц на какой-нибудь бесплатной платформе.