У меня в системе оповещения рабочих станций реализованы через COM+ события.
Соответственно есть класс событий и класс-подписчик — EventClass и SubscriberClass

Все работает пока на сервере есть пользователь (сделан логин).
Но как только пользователя нет — события перестают приходить. Это можно решить, если установить запуск EventClassApp от имени конкретного сетевого пользователя.
Но есть еще один момент — на события кроме клиентских программ подписан сервис, запущенный на сервере.
Получается, что если не сделать логин на сервере до запуска этого сервиса — он собыия получить не может, т.к. COM+ не может создать экземпляр SubscriberClass.
Если подписчику тоже установить запуск от конкретного пользователя — событие не приходит никому
Помогите пожвлуйста!
Неужели такое нельзя сделать на COM+? Зачем тогда вообще нужны эти события?!

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

T>Все работает пока на сервере есть пользователь (сделан логин).
T>Но как только пользователя нет — события перестают приходить. Это можно решить, если установить запуск EventClassApp от имени конкретного сетевого пользователя.
T>Но есть еще один момент — на события кроме клиентских программ подписан сервис, запущенный на сервере.
T>Получается, что если не сделать логин на сервере до запуска этого сервиса — он собыия получить не может, т.к. COM+ не может создать экземпляр SubscriberClass.
По умолчанию для COM+ приложений стоит identity = interactive user, т.е. текущий залогиненный юзер. Юзера нет, нет identity. Нужно указать конкретного пользователя в identity.

T>Если подписчику тоже установить запуск от конкретного пользователя — событие не приходит никому
Скорее всего, дело в правах. У этого пользователя должен быть доступ к клиентам твоего COM+ приложения. Т.е. к тем, кто к нему подписывается на события.

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

RB>По умолчанию для COM+ приложений стоит identity = interactive user, т.е. текущий залогиненный юзер. Юзера нет, нет identity. Нужно указать конкретного пользователя в identity.
Да, я с этим и пытаюсь справиться...

T>>Если подписчику тоже установить запуск от конкретного пользователя — событие не приходит никому
RB>Скорее всего, дело в правах. У этого пользователя должен быть доступ к клиентам твоего COM+ приложения. Т.е. к тем, кто к нему подписывается на события.
А как это можно настроить?
Т.е. ситуация такая, если подписчик запускается от конкретного пользователя, то если программу запускает этот пользователь или сервис стартует от его имени, то естественно все работает.
Но все остальные пользователи ничего не получают...

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

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

Здравствуйте, 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+ приложение.