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

T>Там такая реализация:
T>Интерфейс IMyEvents — на его основе класс событий
T>Этот же интерфейс реалтзует подписчик.
T>Есть синглтон — локальный дистрибьютер, к которому подключаются локальные подписчики (сервис и программы).
T>Синглтон находится в той же dll, что и подписчик.
T>Клиент реализует интерфейс IMyEvents и подключается к локальному дистрибьютеру.
T>Подписчик получает событие, и через локального дистрибьютера оповещает все приложения.

T>Я так понимаю, что проблема именно с этим синглтоном. Т.е. подписчик получает событие, но оно не доходит по приложений... А как это обойти?
T>Вообще как здесь обойтись без синглтона?

Я сейчас посмотрел, у нас был когда-то проект, в котором использовалась рассылка сообщений через хреновину, лежащую под COM+. Там синглтон сделан "вручную". Т.е. реализован объект, который поддерживает кучу интерфейсов генерации событий, и соответствующие им connection points. Одни и те же интерфейсы используются и для генерации и для приема событий.

Рассылка событий происходит в отдельном рабочем потоке. Клиенты-подписчики создают объекты и делают advise на нужный connection point, передавая синк объектам. В этот момент, каждый объект проверяет наличие рабочего потока (он один на всех), и стартует его при необходимости. В этом рабочем потоке создается "рабочий" объект (все того же самого класса, и ессно, он получается то же один на всех). Объект, который создан клиентом-подписчиком, в своем вызове Advise маршалит интерфейс синка в рабочий поток и кидает сообщение "рабочему" объекту об этом (передает ему стрим). В рабочем потоке ловит сообщение, берет переданный стрим и отдает его "рабочий" объекту. Тот получает отмаршалленный интерфейс синка и делает уже настоящий Advise этого синка к себе. Unadvise происходит по той же схеме. Когда все клиенты-подписчики отмаршалятся, рабочий поток заканчивает работу (и ессно, грохает "рабочий" объект).

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

Вот этот "рабочий" объект — он один, живет в рабочем потоке.

Как настраивались права. Клиенты — обычные приложения, или com-объекты, загруженные в обычные приложения. Все эти com-объекты были зарегистрированы с указанием AppID. В dcomcnfg на машинах клиентов настраивается доступ на access к этому AppID для аккаунта, под которым работает COM+ приложение.