Читать онлайн «C# для профессионалов. Том II». Страница 59

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

Первый: можно спроектировать классы компонентов не имеющих состояния. Это означает, что для них не определяются свойства, которые должны быть заданы перед вызовом методов. Вместо этого значения этих свойств хранятся вне объектов, в самом интерфейсе пользователя, и передаются в качестве входящих в объекты аргументов, когда вызываются их методы. Так как объекты больше не связаны с какими-либо устойчивыми данными, эта схема эффективно сокращает классы до библиотек функций.

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

Состояние объекта представляет интерес не только при использовании пулов объектов, но и при использовании утилит активации JIT. Это следующая рассматриваемая служба COM+.

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

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

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

Мы использовали серверные объекты, которые требуют некоторой инициализации перед тем, как можно будет вызвать их методы. Объект ADODB.Connection является одним из примеров необходимо инициализировать его свойство ConnectionString, прежде чем можно будет приказать ему выполнить запрос SOL. Так как объект в пуле не может сохранять состояние между вызовами, невозможно инициализировать его и вызывать его методы в отдельных шагах. Обращение к объекту в пуле должно передавать в этот объект все значения, которые нужны ему для выполнения работы.

Существует два аспекта в модели безопасности, которую предоставляют службы COM+

Первым аспектом является аутентификация. Вкратце службы COM+ позволяют наложить ограничения на того, кто имеет доступ к служебным компонентам и методам, которые они предоставляют. Используя snap-in службы компонентов, можно задать уровень аутентификации приложения для определения того, когда выполняется аутентификация — при соединении клиента с серверным объектом, для каждого сетевого пакета коммуникации для объекта, при вызове каждого метода и т.д.

Вторым аспектом модели безопасности служб COM+ является уровень заимствования прав компонента. Так как серверный объект выполняет работу от имени клиента, то может быть полезно предоставлять для серверного объекта привилегии доступа и идентичности клиента, которого он обслуживает. Уровень заимствования прав позволяет это сделать.

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

Мы обсудим безопасность на основе ролей для сборки .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+ ставят сообщение в очередь к недоступному серверному объекту и возвращают управление клиенту, они не могут вернуть сложный ответ. По этой причине необходимо принимать в расчет возможность возникновения неподтвержденных ошибок при проектировании компонентов, которые используют очереди сообщений. Более того, нельзя использовать значения, возвращенные из компонентов очереди, для выполнения обработки. Если компоненты отключены, они не могут возвращать значения.