Мы обсудим безопасность на основе ролей для сборки .NET позже в этой главе.

До сих пор мы говорили о службах COM+, которые могут быть уже знакомы из MTS. Теперь давайте перейдем к обсуждению служб, введенных вместе с COM+.

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

Эту новую службу событий часто называют "моделью издателя-подписчика". При таком подходе разрабатывается интерфейс события и затем он регистрируется в службах COM+. Затем регистрируются классы, которые хотят иметь возможность инициировать события, определенные в интерфейсе как издатели. После этого регистрируются классы, которые хотят иметь возможность обрабатывать события, определенные в интерфейсе события как подписчики. Когда объект издателя/сервера инициирует событие, службы COM+ отвечают за уведомление всех подписчиков. Так как классы-подписчики не соединены напрямую с классами-издателями, а вместо этого используют службы COM+ в качестве посредника, то архитектуру часто описывают как "слабосвязанные" события.

Чтобы реализовать эту схему, необходимо выполнить следующие шаги:

1. Создать DLL класса события, которая реализует интерфейс события.

2. Зарегистрировать DLL класса события в службах COM+.

3. Создать серверный компонент, который внутренне создает экземпляр класса события и вызывает методы на этом экземпляре, чтобы инициировать события.

4. Зарегистрировать серверный компонент как издателя в службах COM+.

5. Создать клиентские компоненты, которые реализуют интерфейс события, чтобы перехватывать события.

6. Зарегистрировать клиентские компоненты как подписчиков в службах COM+.

Когда эти шаги завершены, класс издателя может инициировать событие, просто создавая экземпляр класса события и вызывая один из его методов. Как отмечено выше, службы COM+ сообщат каждому классу-подписчику, что было инициировано событие. Однако, несмотря на надежность такого подхода, существует, по крайней мере, два недостатка в способе, которым службы COM+ реализуют эту модель событий.

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

□ Второй: по крайней мере во время написания книги службы COM+ не имели возможности инициировать события от объектов-издателей для объектов-подписчиков на других машинах.

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

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

Служба очередей сообщений из COM+ позволяет разработчикам отказаться от кодирования ситуаций отсутствия соединения. Вкратце, служба очередей записывает вызовы методов от клиентских объектов к серверным объектам, которые недоступны, так что они могут быть отправлены назад серверному объекту, когда он снова будет доступен в сети. Клиентский код остается в полном неведении, что произошло что-то неординарное и что службы COM+ действовали в качестве посредника.

Как можно представить, очереди сообщений будут удобным средством при создании приложений, которые должны выполняться на машинах со связью и без связи. К тому же, очереди сообщений являются составной частью сервера BizTalk компании Microsoft — новой серверной программы, делающей возможным процесс перемещения данных внутри и между организациями. При установке Windows 2000 Server очереди сообщений являются одной из возможностей, которую можно установить или отбросить.

Несмотря на свои достоинства, очереди сообщений имеют также серьезные ограничения. Очевидно, что когда службы COM+ ставят сообщение в очередь к недоступному серверному объекту и возвращают управление клиенту, они не могут вернуть сложный ответ. По этой причине необходимо принимать в расчет возможность возникновения неподтвержденных ошибок при проектировании компонентов, которые используют очереди сообщений. Более того, нельзя использовать значения, возвращенные из компонентов очереди, для выполнения обработки. Если компоненты отключены, они не могут возвращать значения.

Даже с теми возможностями, которые предоставляют пулы объектов, а также оперативная активизация для максимального доступа серверных ресурсов, возникают ситуации, когда одна серверная машина просто не может обслужить всех прикладных клиентов. В таких случаях разработчики должны воспользоваться службой COM+ выравнивания нагрузки компонентов. Эта служба распределяет прикладные объекты по ферме совместно действующих серверов Web, чтобы ни один сервер не был перегружен объектными запросами и чтобы конечные пользователи продолжали работать с высокой производительностью.