C# для профессионалов. Том II
Шрифт:
По своей природе пул объектов может позволить использовать один и тот же экземпляр объекта нескольким различным клиентским процессам. Это означает, что если один из этих процессов изменит состояние общего объекта перед тем, как откажется от него, новое состояние будет видно следующему процессу, который получит объект, даже если это состояние будет не тем, которое ожидает наследующий процесс. Существует пара способов обойти эту проблему.
Первый: можно спроектировать классы компонентов не имеющих состояния. Это означает, что для них не определяются свойства, которые должны быть заданы перед вызовом
Второй: можно наделить компоненты интеллектом, необходимым для сериализации и восстановления ими своего состояния.
Состояние объекта представляет интерес не только при использовании пулов объектов, но и при использовании утилит активации JIT. Это следующая рассматриваемая служба COM+.
Оперативная активизация (JIT)
Поскольку создание экземпляров объектов тратит серверные ресурсы, разработчики вынуждены учитывать это. В частности, они должны гарантировать, что интенсивно используемые многопользовательские программы с большим объемом трафика создают объекты только, когда требуется, и удаляют их из памяти сразу после использования. К счастью для нас, службы COM+ предоставляют другой подход, который освобождает разработчика от этих проблем.
При оперативной активизации разработчик может создать экземпляры своих объектов один раз в начале программы и затем использовать их, когда они понадобятся, не беспокоясь о ресурсах, которые они потребляют в спящем режиме. Неявно службы COM+ освобождают пространство, занимаемое объектами, когда они не используются, и восстанавливают их в тот момент, когда клиентский код вызывает их методы. Таким образом, клиентский код может содержать ссылки на множество объектов сколько угодно времени, уверенный, что службы COM+ предоставят объекты, когда понадобится, и освободят их память, как только будет возможно.
Подобно классам в пулах, активированные JIT классы должны разумно управлять состоянием. Если службы COM+ освобождают пространство, занимаемое объектом между последовательными обращениями к нему, то нет гарантии, что те же значения свойств будут сохраняться между первым и вторым вызовом.
Мы использовали серверные объекты, которые требуют некоторой инициализации перед тем, как можно будет вызвать их методы. Объект
Безопасность
Существует два аспекта в модели безопасности, которую предоставляют службы COM+
Первым аспектом является аутентификация. Вкратце службы COM+ позволяют наложить ограничения на того, кто имеет доступ к служебным компонентам и методам, которые они предоставляют. Используя snap-in службы компонентов, можно задать уровень аутентификации приложения
Вторым аспектом модели безопасности служб COM+ является уровень заимствования прав компонента. Так как серверный объект выполняет работу от имени клиента, то может быть полезно предоставлять для серверного объекта привилегии доступа и идентичности клиента, которого он обслуживает. Уровень заимствования прав позволяет это сделать.
Безопасность на основе ролей является соглашением, связываемым обычно с клиент-серверными приложениями, которые используют службы COM+. При таком подходе серверный объект проверяет сначала, принадлежит ли его клиент определенной роли безопасности Windows, прежде чем выполнять работу от его имени.
Мы обсудим безопасность на основе ролей для сборки .NET позже в этой главе.
Новые службы COM+
До сих пор мы говорили о службах COM+, которые могут быть уже знакомы из MTS. Теперь давайте перейдем к обсуждению служб, введенных вместе с COM+.
События
Одной из новых служб, которую предлагает COM+, является механизм событий, архитектура которого отличается от традиционного механизма использования точек соединения.
Эту новую службу событий часто называют "моделью издателя-подписчика". При таком подходе разрабатывается интерфейс события и затем он регистрируется в службах COM+. Затем регистрируются классы, которые хотят иметь возможность инициировать события, определенные в интерфейсе как издатели. После этого регистрируются классы, которые хотят иметь возможность обрабатывать события, определенные в интерфейсе события как подписчики. Когда объект издателя/сервера инициирует событие, службы COM+ отвечают за уведомление всех подписчиков. Так как классы-подписчики не соединены напрямую с классами-издателями, а вместо этого используют службы COM+ в качестве посредника, то архитектуру часто описывают как "слабосвязанные" события.
Чтобы реализовать эту схему, необходимо выполнить следующие шаги:
1. Создать DLL класса события, которая реализует интерфейс события.
2. Зарегистрировать DLL класса события в службах COM+.
3. Создать серверный компонент, который внутренне создает экземпляр класса события и вызывает методы на этом экземпляре, чтобы инициировать события.
4. Зарегистрировать серверный компонент как издателя в службах COM+.
5. Создать клиентские компоненты, которые реализуют интерфейс события, чтобы перехватывать события.
6. Зарегистрировать клиентские компоненты как подписчиков в службах COM+.
Когда эти шаги завершены, класс издателя может инициировать событие, просто создавая экземпляр класса события и вызывая один из его методов. Как отмечено выше, службы COM+ сообщат каждому классу-подписчику, что было инициировано событие. Однако, несмотря на надежность такого подхода, существует, по крайней мере, два недостатка в способе, которым службы COM+ реализуют эту модель событий.
□ Первый: так как объекты подписчики уведомляются об инициированных событиях по одному за раз, объект каждого подписчика имеет потенциальную возможность ждать других, если его обработчик событий работает медленно.