Добрынин В.Ю. Технологии компонентного программирования

Подождите немного. Документ загружается.

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

разумно сконфигурировать как асинхронные и всех подписчиков. В этом случае подсистема событий не будет иметь

проблем с подписчиками, которые должны быть активированы на машинах, к которым временно нет доступа. Кроме

того, это даст возможность администратору машины, на

которой активируется подписчик, управлять процессом

получения уведомлений, выделяя для этого удобное время.

{ Поддержка транзакций событийным классом

В ряде случае удобно конфигурировать и событийный класс и всех его подписчиков как поддерживающих

транзакции. Тогда издатель может инициировать транзакцию, исход которой определяется всеми подписчиками.

{ Безопасность

Очевидна роль системы безопасности в распределенном приложении. Подсистема событий вносит сюда свою

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

доступна только администраторам машины, на которой выполняется регистрация. Такая политика повышает уровень

безопасности, но и накладывает дополнительную нагрузку на администраторов.

Издатель, событийный класс и подписчик

могут использовать все возможности, предлагаемые системой безопасности

в COM+. Например, подписчик может выяснить, является ли издатель события тем, за кого себя выдает.

Среди специфических именно для событийного класса настроек имеется возможность разрешить подписчикам,

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

сократит время уведомления подписчиков, но понизит

уровень безопасности, т.к. в этом случае подписчик сможет

выполнять различные вызовы от лица издателя.

{ Параллельнная рассылка уведомлений

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

не определенном порядке. При этом возникает следующая проблема. Вызов подписчика сводится к вызову некоторого

реализованного им метода событийного интерфейса. Какова реализация этого метода, как долго этот метод будет

выполняться - подсистеме событий неизвестно. Но передача уведомления следующему

подписчику в данном случае

будет выполнена только после завершения передачи уведомления предыдущему подписчику. Это означает, что

подсистема событий не может гарантировать временной интервал, в рамках которого все подписчики получат

уведомления.

Потребовав параллельную рассылку уведомлений для данного класса событий, администратор просит подсистему

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

Более кардинальное решение проблемы связано с использованием фильтра на стороне издателя, что будет

рассмотрено позднее.

{ Идентификатор издателя

Cобытийному классу можно приписать уникальный идентификатор издателя. Это позволяет подписываться на

события, распространение которых инициируется конкретным издателем.

Имеется еще один важный параметр класса событий, задание которого возможно только программным путем (используя

административные компоненты для работы с COM+ каталогом) после регистрации событийного класса. Это свойство

событийного класса

MultiInterfacePublisherFilterCLSID. Данное свойство задает CLSID специального класса - фильтра, который на стороне

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

z Активация экземпляра событийного класса и инициализация рассылки уведомлений

Активация экземпляра событийного класса выполняется издателем, желающим инициировать рассылку уведомлений о

наступлении некоторого события. Издатель формирует экземпляр событийного класса, вызывая, например, функцию

CoCreateInstance. Далее, получив указатель на событийный интерфейс данного событийного класса, он вызывает

некоторый метод этого интерфейса, инициируя тем самым рассылку уведомлений всем подписчикам. Особенностью

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

реализацию событийного интерфейса, обеспечивая активацию подписчиков и вызов соответствующего реализованного

каждым подписчиком метода событийного интерфейса.

Заметим, что в процесс рассылки уведомлений могут вмешаться два

фильтра - фильтр со стороны издателя и фильтр со стороны подписчика.

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

то он может проанализировать код возврата типа

HRESULT, который может принимать одно из следующих значений:

{ S_SUCCESS - уведомления были доставлены всем подписчикам.

{ EVENT_S_SOME_SUBSCRIBERS_FAILD - код успешного в целом завершения рассылки, однако доставка уведомлений

некоторым подписчикам завершилась неудачей. Заметим, что на этом этапе невозможно определить подписчиков, не

получивших уведомлений.

{ EVENT_E_ALL_SUBSCRIBERS_FAILD - неудача, никто из подписчиков не получил уведомления.

{ EVENT_S_NOSUBSCRIBERS - операция завершилась успехом, но подписчики на данное событие отсутствуют.

Издатель, подписчик и подписка

Исходя из вышеизложенного, издателем может выступать любой компонент (программа), имеющий право активировать

экземпляр событийного класса и вызвать некоторый его метод. Никакой специальной регистрации в подсистеме событий не

требуется. Для использования универсального маршалинга ( маршалинга библиотеки типов) необходимо зарегистрировать на

машине издателя библиотеку типов событийного класса.

Подписчиком является обычный COM+ компонент,

еализующий событийный интерфейс. Особенностью является его

егистрация не только на той машине, где он должен быть активирован в соответствии с логикой приложения (например, на

машине пользователя, заинтересованного в получении информации о наступлении события), но и на той же машине, на которой

зарегистрирован событийный класс. Последнее необходимо для оформления подписки.

По поводу подписки следует заметить, что существует три

ее типа:

z Постоянная

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

некоторого метода событийного интерфейса издателем формируется новый экземпляр каждого подписчика, который

обрабатывает переданный ему вызов и уничтожается после возврата из вызванного метода. Это обеспечивается тем, что

подсистема событий имеет информацию о CLSID каждого подписчика и машине, на которой его следует

активировать.

z Временная

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

класса подписчика активируется не подсистемой событий, а некоторым приложением. После этого выполняется подписка, в

результате которой подсистема событий получает указатель на событийный интерфейс объекта-подписчика. После

получения и обработки уведомления о событии объект-подписчик не

уничтожается и может принимать новые уведомления.

z PerUser

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

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

создан объект-подписчик. Подписка включается подсистемой событий только при входе пользователя с данным SID в

систему и отключается при

его выходе из системы.

Как и в случае регистрации событийного класса, зарегистрировать подписку может только администратор, используя

программирование и/или Component Services. Каждая подписка на некоторое событие является объектом, хранимым в подсистеме

событий. Подписаться можно на событийный интерфейс в целом (на все его методы) или на некоторый метод событийного

интерфейса. Если необходимо подписаться

на несколько методов событийного интерфейса (но не на все), нужно отдельно

оформить подписку для каждого метода. Заметим, что подписчик должен реализовать все методы событийного интерфейса.

Начнем с программной регистрации подписки:

z Прежде всего формируется экземпляр реализованного в системе класса с идентификатором CLSID_CEventSubscription

(объект подписки) и запрашивается указатель на интерфейс

IEventSubscription этого класса. .

z Интерфейс IEventSubscription используется для задания свойств объекта подписки:

{ GUID регистрируемой подписки задается вызовом метода

IEventSubscription::put_SubscriptionID(), где параметром является BSTR строка, задающая GUID подписки.

Этот идентификатор должен быть уникален в данном сервисе событий.

{ Имя регистрируемой подписки задается вызовом метода

IEventSubscription::put_SubscriptionName(), где параметром является BSTR строка, задающая название

подписки. Это читаемая строка, предназначенная для администраторов.

{ Уникальный идентификатор издателя задается вызовом метода IEventSubscription::put_PublisherID(), где

параметром является BSTR строка, задающая GUID издателя. Если эта информация не задана, то подписчик будет

получать уведомления вне зависимости от того, какой издатель инициировал рассылку уведомлений через данный

событийный класс.

{ CLSID событийного класса задается вызовом метода

IEventSubscription::put_EventClassID(), где параметром является BSTR строка, задающая CLSID событийного

класса, для получения уведомлений от которого и регистрируется данная подписка.

{ Идентификатор событийного интерфейса, на который регистрируется подписка (а событийный класс может

реализовывать несколько событийных интерфейсов) задается вызовом метода

IEventSuscription::putInterfaceID, параметр типа BSTR задает GUID этого интерфейса.

{ Метод IEventSubscription::putMethodName вызывается для задания метода событийного интерфейса, на который

регистрируется подписка. Параметром является BSTR строка, задающая название метода.

{ Вызов метода IEventSubscription::putSubscriberCLSID с параметром типа BSTR строка, задающим CLSID

подписчика, используется в случае постоянной подписки. Данный CLSID будет использоваться подсистемой

подписки для активации подписчика.

{ Вызов метода IEventSubscription::putMashineName позволяет в виде BSTR строки задать имя машины, на которой

следует в случае постоянной подписки активировать подписчика.

{ Вызов метода IEventSubscription::putSubscriberInterface используется для организации временной подписки. В

качестве параметра передается маршалированный указатель (типа

IUnknown*) на интерфейс уже активированного

подписчика, на который следует посылать уведомления.

{ Вызов метода IEventSubscription::putPerUser позволяет задать подписку третьего типа, когда подписка действует

только при входе в систему определенного пользователя - владельца подписки. Этот вариант используется только в

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

типа

BOOL включает или выключает это ограничение на подписку.

{ Задать владельца подписки можно вызывая метод

IEventSuscription::putOwnerSID, параметр типа BSTR задает Security ID владельца подписки.

z Формируется экземпляр реализованного в системе класса с идентификатором CLSID_CEventSystem и запрашивается

указатель на его интерфейс

IEventSystem.

z Вызывается метод Store этого интерфейса, которому в качестве первого параметра передается PROGID_EventSubscription,

что указывает на то, что сохраняется именно объект-подписка, а в качестве второго параметра передается указатель на

интерфейс

IEventClass экземпляра класса с идентификатором CLSID_CEventSubscription, параметры которого настроены

на регистрируемую подписку.

Фильтр на стороне издателя

По умолчанию система событий рассылает уведомления о некотором событии всем заинтересованным подписчикам. Однако, в

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

подписчиков, которым будут посланы уведомления, так и на порядок их рассылки. Например, издатель желает отобрать

подписчиков, заплативших за подписку, и отправить уведомления

в первую очередь своим постоянным клиентам. Обе цели могут

быть достигнуты путем использования фильтра на стороне издателя.

Выше, при обсуждении свойств событийного класса упоминалось, что свойству

MultiInterfacePublisherFilterCLSID можно

программным путем присвоить CLSID некоторого класса, который будет рассматриваться подсистемой событий как фильтр,

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

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

подписчиками и здесь не рассматриваемый) издательский фильтр должен реализовывать интерфейс

IMultiInterfacePublisherFilter с двумя методами:

z Initialize

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

издательский фильтр (если свойство

MultiInterfacePublisherFilterCLSID было задано). В случае какой-либо ошибки при

активации фильтра не будет активирован и событийный объект. После активации фильтра подсистема событий сразу же

вызывает метод Initialize, которому в качестве единственного параметра (входного) передается указатель на

реализованный в системе интерфейс

IMultiInterfaceEventControl. Через этот интерфейс фильтр может получить доступ

к коллекции подписчиков на произвольный событийный интерфейс и метод в событийном классе, для которого и

подготовлен данный фильтр. Достаточно вызвать метод

IMultiInterfaceEventControl::GetSubscriptions, среди параметров которого:

{ [in] Идентификатор событийного интерфейса.

{ [in] Метод событийного интерфейса. Если название метода не существенно, то значение параметра NULL.

{ [in] Критерий отбора объектов-подписок для включения в коллекцию подписок. Здесь задается BSTR сторка,

представляющая логическое выражение, в которое входят свойства подписки, операторы отношения, константы,

логические операторы и скобки. Если параметр равен NULL, то используется некоторый критерий отбора по

умолчанию.

{ [out] Указатель на IEventObjectCollection.

ерез этот интерфейс фильтр получает доступ к коллекции отобранных

объектов-подписок и может в дальнейшем определять порядок их оповещения.

Заметим, что построенная при вызове

IMultiInterfaceEventControl::GetSubscriptions коллекция автоматически обновляется при добавлении/удалении

подписок на данный событийный интерфейс (метод) в подсистеме событий.

z PrepareToFire

Данный метод собственно и осуществляет перехват процесса рассылки уведомлений. Как только издатель вызывает

некоторый метод событийного интерфейса, инициируя тем самым рассылку уведомлений подписчикам, подсистема

событий вместо обычного процесса рассылки уведомлений всем подписчикам в некотором заранее неопределенном

порядке, вызывает метод

PrepareToFire, предоставляя фильтру возможность определить кому и в каком порядке следует

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

Вот параметры этого метода:

{ [in] Идентификатор событийного интерфейса

{ [in] Метод событийного интерфейса

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

{ [out] Указатель на интерфейс IFiringControl

Это интерфейс реализован в системе. Фильтр использует его для вызова метода

IFiringControl::FireSubscription.

Этот метод принимает в качестве единственного (входного) параметра указатель на интерфейс

IEventSubscription

объекта-подписки, которому следует отправить уведомление о событии. Именно здесь фильтр может определить

подписчиков и порядок рассылки им уведомлений.

Фильтр на стороне подписчика

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

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

уведомления о курсе акций всех компаний на рынке или даже о колебаниях курса акций интересующей его компании, пока этот

курс не достиг заданной величины.

Среди свойств объекта-подписки имеется свойство FilterCriteria. Это свойство администратор может задавать при регистрации

подписки с помощью Component Services. Критерий фильтрации задается логическим выражением, содержащим параметры

событийного метода, операторы отношений, константы, логические операторы и скобки. Таким образом, задав критерий

фильтрации, администратор устанавливает так называемое параметрическую фильтрацию, результат которой

определяется

значениями параметров вызываемого метода событийного интерфейса. Данная фильтрация выполняется естественно после

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

той же машине, где зарегистрирован событийный класс, никакие излишние вызовы на машину, где обычно активируется

подписчик, не выполняются. Естественно, и сам подписчик

активируется если только направляемое ему уведомление преодолело

параметрический фильтр.

.NET Framework от Microsoft

Введение

.NET во многом революционизирует программирование под Windows. Это большая и сложная технология, которая требует от

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

Остановимся прежде всего на некоторых вопросах, касающихся тенденций развития программирования за последние

десятилетия. Почти до самого конца 20 века все наиболее распространенные технологии программирования ориентировались на

вычислительные машины, разработка архитектуры которых приписывается американскому математику фон Нейману. Этот

период можно охарактеризовать как централизованное программирование централизованных систем. Иными словами,

программирование системы контролируется из одного

центра и сама разрабатываемая система имеет централизованное

управление.

В последнее десятилетие 20 века огромное влияние на определение путей дальнейшего развития технологии программирования

оказывает Интернет. Глобальная сеть предстает перед программистами как новая вычислительная система, для

программирования которой нужны новые технологии. Эти новые технологии должны учитывать децентрализованность на всех

уровнях. Физически сеть состоит

из множества узлов, соединенных каналами ограниченной пропускной способности. На

логическом уровне единая система может создаваться независимо работающими, не знающими друг о друге разработчиками,

использующими различные платформы и языки программирования. Организационно различные части системы могут

управляться различными лицами и организациями. Как следствие особое внимание должно уделяться вопросам безопасности,

надежности и масштабируемости проектируемых

приложений.

Ранее в данном курсе упомянутые вопросы уже рассматривались при рассмотрении технологии COM (COM+). Новая технология

(.NET) во многом основана на идеях COM. Пришло время, когда все программисты, работающие на платформе Windows, должны

будут познакомиться с этими идеями.

Данный раздел посвящен введению в .NET. Обычно такое введение посвящено беглому рассказу о всех технологиях .NET,

включая и работу

с базами данных, и с Web, и методы построения пользовательского интерфейса. Данный курс посвящен

компонентному программированию и упор будет сделан именно на компоненты.

В .NET о компонентах говорится особо. Имеется пространство имен

System.ComponentModel, в котором определяются классы и

интерфейсы, поддерживающие некоторую модель компонентного программирования. В рамках этой модели компонентами

называются классы (производные от некоторых специальных классов или реализующие некоторые специалные интерфейсы),

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

значительно шире. В данном курсе понятие компонента

не определяется строго. Неформально понятие компонент связывается с

технологией, ориентированной на распределенное программирование распредеденных систем. Базы данных, интерфейс

пользователя - это важные темы, но они не относятся исключительно к распределенным системам и, в связи с этим, не

затрагиваются в данном курсе.

Можно выделить две компонентные модели, поддерживаемые технологией .NET. Во-первых, это уровень

CLR (Common

Language Runtime) - основа всей технологии .NET. Данная модель наиболее близка к COM. Во-вторых, это очень популярная

сегодня модель XML Web-сервисов, в рамках которой возможно взаимодействие программ, исполняющихся на разных

платформах при условии, что взаимодействующие программы понимают протокол SOAP.

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

как COM

и COM+. И изложение будет основано на сопоставлении компонентной модели COM и модели, поддерживаемой в CLR.

Интерфейсы

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

перекомпиляции может работать с разными версиями компонента. Кроме того, интерфейсы обеспечивают в COM независимость

от языка программирования, на котором написаны клиент и компонент.

В COM и в COM+ мы видим огромное множество интерфейсов, совокупность которых можно рассматривать как

некоторое

компонентно - ориентированное расширение базового языка программирования (например, C++). Стоит отметить, что изучать

эти интерфейсы весьма не просто в силу их многочисленности и отсутствия единой систематизирующей структуры.

Роль интерфейсов в .NET резко сокращена. На взгляд автора, теперь интерфейсы прежде всего служат для расширения множества

типов, приписанных данному классу. В отличие от COM, где

не было наследования реализации, в .NET класс может наследовать

одному классу (по умолчанию классу

System.Object) и любому числу интерфейсов, которые не имеют реализации и не

наследуют корневому классу

System.Object.

Относительное снижение значимости интерфейсов в .NET по сравнению с COM в .NET компенсируется следующим:

z Клиент больше не изолируется от компонента

Если в COM клиент был максимально изолирован от компонента, то в .NET ему доступна разнообразная информация о

компоненте. Это обеспечивается тем, что в коде компонента хранятся описывающие его метаданные, доступ к которым

клиент может получить используя механизм рефлексии.

z Многие интерфейсы более не нужны

Многие интерфейсы, играющие важную роль в COM, более не нужны в .NET. С помощью представленного ниже примера

будет объяснено, почему, например, стал не нужен базовый интерфейс для COM -

IUnknown. Те возможности, которые

ранее программисты получали за счет реализации и использования большого числа интерфейсов, теперь можно получить за

счет использования среды разработки и исполнения, предоставляемой .NET. Это и CLR, и общая система типов CTS, и

промежуточный язык MSIL, на который транслируются программы со всех других языков, поддержанных .NET.

Сервер в процессе клиента

Рассмотрим в качестве примера процесс построения и использования сервера, который в рамках COM-терминологии получил бы

классификацию "сервер в процессе клиента", т.к. он будет исполняться в адресном процессе клиента. Код представлен на C#.

Сервер

using System;

namespace MyServer {

public interface IAccumulator{

void Add(int sum);

}

public interface IAudit{

int Total();

}

public class Account: IAccumulator, IAudit{

protected int _sum = 0;

public void Add(int sum){

_sum += sum;

}

public int Total(){

Console.WriteLine("Server AppDomain = {0}",

AppDomain.CurrentDomain.FriendlyName);

return _sum;

}

лиент

using System;

using System.Reflection;

using MyServer;

public class MyApp {

public static void Main() {

Account a = new Account();

IAccumulator iAcc = a as IAccumulator;

if (iAcc != null){

iAcc.Add(3);

iAcc.Add(5);

}

IAudit iAud = iAcc as IAudit;

if (iAud != null)

Console.WriteLine("Total = {0}", iAud.Total());

Console.WriteLine("Client AppDomain = {0}\n",

AppDomain.CurrentDomain.FriendlyName);

Type iAuditType = iAud.GetType();

MethodInfo[] Methods = iAuditType.GetMethods();

foreach (MethodInfo Method in Methods){

Console.WriteLine(Method.ToString());

}

В данном примере сервер реализован классом Account. Этот класс реализует два интерфейса:

z IAccumulator

Этот интерфейс позволяет клиенту отправлять на счет, поддерживаемый сервером, некоторую сумму (метод

Add)

z IAudit

Данный интерфейс позволяет клиенту узнать текущее состояние счета (метод

Total)

И интерфейсы, и реализующий их класс

Account определяются в рамках одного пространства имен MyServer.

Стоит еще обратить внимание на то, что метод

Total не только возвращает текущую сумму на счете, но и выводит на консоль

имя домена приложения, в котором выполняется сервер. Тут необходимы дополнительные пояснения. Управляемый код,

порождаемый компилятором с C# и использующий все сервисы CLR, является типо-безопасным кодом, который в процессе

своего выполнения не может повредить данные, к которым он не должен

иметь доступа. Это позволяет в рамках одного процесса

организовать несколько логических процессов - доменов приложений (Application Domain), которые делят одно адресное

пространство и границу между которыми может пересекать поток. Каждое приложение работает в рамках одного домена

приложения. За счет "легковестности" доменов приложений, их использование более эффективно, чем использование для

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

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

Теперь обратимся к клиенту. Используется пространство имен

MyServer, в котором определен класс Account. Кроме того,

используется пространство имен

System.Reflection. В этом пространстве определены классы, обеспечивающие механизм

рефлексии, т.е. доступ к метаданным.

Клиентское приложение является консольным приложением. Функция

Main обеспечивает точку входа. Оператор new

обеспечивает построение экземпляра класса

Account. При этом нет необходимости предварительно регистрировать сервер в

реестре и при его активации задавать соответствующий

CLSID. Нет и никаких фабрик классов.

Разберем вопрос, связанный с базовым COM-интерфейсом

IUnknown.

Во-первых, теперь нет нужды в методе QueryInterface. Оператор as позволяет безопасно привести ссылку на объект к ссылке на

любой реализуемый им интерфейс. Если полученная ссылка на интерфейс

IAccumulator не равна null, то это означает, что класс

Account действительно реализует интерфейс IAccumulator и клиент может отправить на счет две суммы (3 и 5), используя метод

Add.

Теперь, имея ссылку на интерфейс

IAccumulator, можно перейти к ссылке на интерфейс IAudit. В случае реализации этого

интерфейса вызывается его метод

Total и на консоль выводится сумма счета и имя домена приложения, в котором выполняется

клиент.

Во-вторых, кардинально меняется подход к управлению памятью. Заметим, что мы не освободили память, отведенную под

экземпляр класса

Account. В COM управление временем жизни объекта выполняется с помощью подсчета числа сделанных на

него ссылок. Когда число ссылок становится равным 0, объект вызывает собственный деструктор.

Этот механизм имеет много недостатков. Тут и ошибки при подсчете сделанных ссылок (клиент должен вызывать методы

AddRef

и Release интерфейса IUnknown соответственно при получении новой ссылки на объект и при ее освобождении), и возможность

появления циклических ссылок, при наличии которых счетчик числа ссылок на некоторые объекты никогда не обратится в 0. Во

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

В .NET используется автоматическое управление выделением и освобождением памяти.

Менеджер кучи быстро выделяет память

для вновь создаваемых объектов благодаря наличию указателя на начало непрерывного свободного пространства в куче. Если

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

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

объекты

, и перемещает их образы в куче к ее началу, модифицируя все адреса перемещаемых объектов в данных и в коде. Вся

остальная часть кучи после последнего используемого объекта считается свободной.

Конечно, со сборкой мусора связаны свои проблемы:

z Недетерминированность

Момент начала сборки мусора заранее как правило не известен. Если объект связывает ценные ресурсы (открытые файлы,

соединения с базой данных), то клиент должен явно вызвать метод

Dispose, в котором объект должен реализовать

освобождение упомянутых и других ценных ресурсов не дожидаясь начала работы сборщика мусора.

Если надежд на клиента мало, класс должен реализовать метод

Finalize, в котором также должно выполняться

освобождение ресурсов. В отличие от метода

Dispose, метод Finalize вызывается автоматически во время сборки мусора

до уничтожения объекта.

z Распределенная сборка мусора

Сборщик мусора не имеет доступа к удаленным объектам. Их освобождение регулируется другим механизмом, т.н.

лизингом (leasing).

Последняя часть кода клиента демонстрирует применение механизма рефлексии. Цель - вывести на консоль сигнатуры всех

методов, которые доступны через интерфейс

IAudit. Заметим, что это будут не только все методы, реализованные в классе

Account, но и все методы, реализованные в корневом классе System.Object, от которого неявно наследуют все классы в .NET, в

том числе и класс

Account.

Наследуемый метод GetType позволяет получить ссылку на объект типа Type, содержащий всю нужную информацию. Далее

формируется массив всех доступных методов и в цикле на консоль выводится сигнатура каждого доступного метода.

Таким образом, механизм рефлексии предоставляет ту информацию, которая в рамках COM хранилась в

IDL-файлах, в

заголовочных файлах, в библиотеке типов.

Теперь рассмотрим вопросы компиляции и развертывания построенного приложения.

Важнейшее новшество в .NET - понятие сборки, которую можно рассматривать как логическую DLL. Сборки позволяют

различным клиентам работать с различными версиями одного и того же компонента. Сборка содержит метаданные (манифест),

используя которые система может еще до запуска клиента

узнать - имеются ли все нужные клиенту компоненты в доступных

сборках.

Предположим, что код клиента содержится в файле

MyApp.cs рабочего каталога, а код сервера в подкаталоге MyServer в файле

MyServer.cs. Следующие команды обеспечивают компиляцию и сборку клиентского и серверного приложений:

>csc /t:library MyServer.cs

>csc /r:MyServer\MyServer.dll MyApp.cs

В первой строке вызывается компилятор с C# и код сервера MyServer.cs компилируется в сборку MyServer.dll.

Ключ

/t:library говорит именно о том, что нужна сборка типа DLL, т.е. ее можно загружать в домен клиентского приложения.

Во второй строке компилируется код клиента

MyApp.cs. По умолчанию получаем сборку MyApp.exe, ключ /r:MyServer

MyServer.dll

дает статическую ссылку на сборку, содержащую компонент Account.

Отметим, что в данном случае сборка с сервером находится в одном каталоге с клиентом (точнее, в его подкаталоге, имя которого

совпадает с именем сборки). Такой способ развертывания является самым простым. Он допускает перенос приложения в другой

каталог, на другую машину простым копированием. Нет никакой регистрации.

Однако данной сборкой может пользоваться

только данный клиент. Другим клиентам, находящимся вне рабочего каталога,

данная библиотечная сборка недоступна.

Теперь запустим клиентское приложение

>csc MyApp.exe

Server AppDomain = MyApp.exe

Total = 8

Client AppDomain = MyApp.exe

Int32 Total()

Void Add(Int32)

Int32 GetHashCode()

Boolean Equals(System.Object)

System.String ToString()

System.Type GetType()

Мы видим, что и сервер и клиент выполняются в одном домене приложения. Его имя совпадает с именем клиентского

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

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

Ниже

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

реализованные в классе

Account, и методы, унаследованные от System.Object.

Регистрация сборки в Global Assembly Cache

GAC - Global Assembly Cache, это то место, где можно развертывать сборки, которые должны быть доступны многим клиентам.

Для развертывания сборки в GAC ее нужно подписать. Точнее, сборке присваивается версия, ее содержимое хешируется и

хешированное значение шифруется личным ключом разработчика. В сборку (в ее манифест), включаются версия сборки,

шифрованный хеш - электронная подпись, публичный ключ. В результате,

благодаря наличию публичного ключа, можно

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

клиентское приложение было откомпилировано.

Ниже приведены все необходимые команды, обеспечивающие подписание сборки и ее регистрацию в GAC:

>csc /t:module MyServer.cs

>sn -k my.snk

>al /out:MyServer.dll MyServer.netmodule /keyfile:my.snk

>gacutil -i MyServer.dll

>sn -Tp MyServer.dll

Public key is

002400000480 . . . . .

Public key token is 047772996d01a6d4

Для получения подписанной сборки (сборки со строгим именем) нужно откомпилировать код сервера с параметром /t:module. В

результате получим модуль

MyServer.netmodule, содержащий (как и сборка) код на MSIL, но не содержащий (в отличие от

сборки) манифеста.

Далее генерируется (если не была сгенерирована ранее) пара ключей - личный и публичный ключи, с помощью утилиты

(strong name). Эта пара записывается в файл

my.snk.

На следующем этапе компоновщик сборки

al (assembly linker) формирует подписанную сборку MyServer.dll, используя модуль

MyServer.netmodule и файл с ключами my.snk.

Для регистрации сборки в GAC можно использовать утилиту gacutil.

Для работы с подписанной сборкой клиент должен знать ее версию и публичный ключ (или его хешированное значение - токен

публичного ключа). Последнее можно получить с помощью утилиты

sn с параметром -Tp, указав подписанную сборку.

В следующем примере демонстрируется клиент, который может воспользоваться зарегистрированной в GAC сборкой. Кроме

этого, в этом примере демонстрируется так называемая динамическая ссылка на сборку.

В случае продемонстрированной в предыдущем примере статической ссылки, которую можно было бы применить и в этом

случае (в случае сборки зарегистрированной в GAC), клиент связывается

с нужной сборкой на этапе компиляции. В этом случае в

манифест сборки клиента записывается вся нужная информация об используемых им сборках. Это позволяет еще до запуска

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

наличии можно гарантировать ее совместимость с клиентом.

Но иногда нужно

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

нужной сборки (и нужного типа в данной сборке) не проверяется.

using System;

using System.Reflection;

public class MyApp {

public static void Main() {

Assembly assem = Assembly.Load("MyServer,"+

"Version=0.0.0.0,"+

"Culture=neutral,"+

"PublicKeyToken=047772996d01a6d4");

Type accountType = assem.GetType("MyServer.Account");

if (accountType != null){

MethodInfo addMethod = accountType.GetMethod("Add");

MethodInfo totalMethod =

accountType.GetMethod("Total");

Object obj = Activator.CreateInstance(accountType);

Object[] args = new Object[1];

args[0] = 3;

if (addMethod != null){

addMethod.Invoke(obj, args);

args[0] = 5;

addMethod.Invoke(obj, args);

}

if (totalMethod != null)

Console.WriteLine("Total = {0}",

totalMethod.Invoke(obj, null));

}

В данном примере статический метод Load класса Assembly загружает из GAC сборку с заданным именем, версией (по

умолчанию 0.0.0.0), культурой (по умолчанию neutral) и токеном публичного ключа. Далее, используя механизм рефлексии,

получаем ссылку на объект типа Type, содержащий всю информацию о классе Account из данной сборки. Если информация об

этом типе имеется в загруженной сборке, получаем информацию о методах

Add и Total. Потом создаем экземпляр класса Account

и формируем массив аргументов. В данном случае массив состоит из одного элемента со значением 3.

Если метод

Add реализован в классе Account, вызываем этот метод на построенном объекте, передавая ему сформированный

массив аргументов. Модифицируем этот массив, занося в него 5, и еще раз вызываем метод

Add.

И, наконец, если метод

Total также реализован, вызываем его без аргументов и выводим полученное значение на консоль.

Дополнительный комментарий по поводу обновления версий компонентов. Как было отмечено выше, при использовании

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

откомпилирован этот клиент, что делает невозможным его запуск с другой

версией этой же сборки. Тем не менее есть

возможность связать клиента с более свежей версией сборки без его перекомпиляции. Для этого используются

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

Удаленный сервер

До сих пор мы рассматривали компоненты, выполняемые в домене клиентского приложения. Этот режим обеспечивает самую

эффективную коммуникацию между клиентом и сервером, но создает проблемы в области надежности и безопасности. Кроме

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

случай и рассматривается в следующем примере

Как и ранее наш сервер принимает вклады, но теперь эти вклады параллельно могут делать различные клиенты. Клиенты и сервер

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

Сервер

//MyServer.cs

using System;

using System.Runtime.Remoting;

using System.Runtime.Remoting.Channels;

using System.Runtime.Remoting.Channels.Http;

namespace MyServer {

public interface IAccumulator{

void Add(int sum);

}

public interface IAudit{

int Total();

}

public class Account: MarshalByRefObject, IAccumulator, IAudit{

protected int _sum = 0;

public void Add(int sum){

_sum += sum;

}

public int Total(){

Console.WriteLine("Server AppDomain = {0}",

AppDomain.CurrentDomain.FriendlyName);

return _sum;

}

public class AccountApp {

public static void Main(){

HttpChannel myChannel = new HttpChannel(8080);

ChannelServices.RegisterChannel(myChannel);

RemotingConfiguration.RegisterWellKnownServiceType(

typeof(Account),

"Account",

WellKnownObjectMode.Singleton);

Console.WriteLine("Server is listening");

Console.ReadLine();

Console.WriteLine("Bye");

}

лиент

//MyApp.cs

using System;

using MyServer;

using System.Runtime.Remoting;

using System.Runtime.Remoting.Channels;

using System.Runtime.Remoting.Channels.Http;

public class MyApp {

public static void Main() {

HttpChannel c = new HttpChannel();

ChannelServices.RegisterChannel(c);

Account a = (Account)Activator.GetObject(

typeof(Account), "http://localhost:8080/Account",

WellKnownObjectMode.Singleton);

a.Add(5);

Console.WriteLine("Total = {0}", a.Total());

Console.WriteLine("Client AppDomain = {0}",

AppDomain.CurrentDomain.FriendlyName);

}

Для использования каналов включаем в код сервера ссылки на пространства имен, содержащие нужные классы :

System.Runtime.Remoting,

System.Runtime.Remoting.Channels,

System.Runtime.Remoting.Channels.Http.

Последнее пространство имен необходимо для работы с каналом, использующим http. Есть возможность работы с tcp каналом

(что в несколько раз быстрее), но http канал по умолчанию передает сообщения по протоколу SOAP в стандартизованном XML

формате, а tcp по умолчанию передает SOAP сообщения в нестандартизованном бинарном формате. Иными словами, при

использовании html канала потенциальный клиент может вообще не принадлежать

миру .NET и платформе Windows.

Необходимо обратить внимание на то, что класс

Account теперь наследует классу MarshalByRefObject. Все объекты в .NET

делятся на три типа:

1. передаваемые по ссылке

2. передаваемые по значению

3. не передаваемые за пределы своего домена приложения

Наш класс должен быть передаваем по ссылке. Это обеспечивается тем, что он наследует классу

MarshalByRefObject. При

работе с таким объектом клиент реально работает не с самим объектом, а с его прокси. Сам же объект формируется удаленно.

Наш удаленный объект должен жить в некотором приложении. Здесь мы описываем консольное приложение, функция

Main (в

коде сервера) - его точка входа.

В данном приложении формируется объект - http-канал (с указанием произвольного номера порта) и этот канал регистрируется в

системе

Remoting.

После этого в этой же системе регистрируется класс, к которому будет обеспечен доступ удаленных клиентов. Задается его тип,

его URI - определяемый разработчиком идентификатор, и режим работы объекта. В данном случае это

Singleton. Это означает,

что такой объект создается после получения первого запроса от какого-либо клиента и далее живет (сохраняя состояние), отвечая

на запросы как этого, так и других объектов.

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

момента сервер ожидает получения сообщений по каналу http на порт 8080. Остановить работу сервера можно нажав на клавишу

<Enter>.

Тепе

ь об

атимся к клиент

. Он

егист

ру

ет один из каналов, за

егист

ованных се

ве

ом

(

но не

казывает номе

по

та

)

Метод Activator.GetObject возвращает ссылку на прокси, сам же объект при этом не создается. Если он не был создан ранее, то

он будет создан при получении первого запроса от какого-либо клиента. Среди параметров задаются тип компонента, путь к нему

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

клиентского приложения.

Теперь рассмотрим результаты работы нашего приложения. В отдельном консольном окне компилируем сервер (создаем сборку

типа .exe) и запускаем его. В другом консольном окне компилируем клиента, задавая ссылку на копию серверной сборки,

размещенной в каталоге клиента. Запускаем клиента два раза и видим, что сумма на

счете накапливается. Кроме того видим, что

сервер и клиент выполняются в различных доменах приложения.

онсоль сервера

>csc /t:exe MyServer.cs

>MyServer.exe

Server is listening

Server AppDomain = MyServer.exe

Bye

онсоль клиента

>csc /r:MyServer\MyServer.exe MyApp.cs

>MyApp.exe

Total = 5

Client AppDomain = MyApp.exe

>MyApp.exe

Total = 10

Client AppDomain = MyApp.exe

Несколько комментариев, касающихся удаленных компонентов.

В .NET определены три типа режимов работы удаленных объектов:

SingleCall

Удаленный объект активируется на стороне сервера только при получении вызова какого-либо его метода от клиента и по

выполнении этого метода сразу же уничтожается.

Singleton

Удаленный объект совместно используется несколькими клиентами, сохраняя состояние между вызовами. Для контроля за

его жизненным циклом используется распределенная сборка мусора - лизинг. При этом объект получает некоторое время

жизни, продлеваемое автоматически после каждого нового вызова. После исчерпания этого времени следует запрос к

спонсору объекта (обычно к самому клиенту) о продлении жизни

компонента. При отсутствии ответа объект уничтожается.

Такой механизм позволяет экономить на коммуникации между клиентом и удаленным сервером.

3. Активируемый клиентом

Такой объект доступен только одному клиенту и сохраняет состояние между вызовами. Для контроля за жизненным циклом

объекта используется лизинг.

Говоря об удаленных компонентах и сопоставляя .NET с COM нельзя не вспомнить об апартаментах.

В одном процессе может

быть несколько апартаментов, и ссылка на объект, полученная в одном апартаменте, не может непосредственно использоваться в

другом апартаменте. Необходимо выполнить ее маршалинг между апартаментами. В .NET такой проблемы нет. Любая объектная

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

И наконец необходимо упомянуть о передаче

объектов по значению. Это возможно и полезно если объект небольшой. В этом

случае клиент получает не прокси на объект, а его копию. Для передачи объекта по значению необходимо, чтобы

соответствующий класс был определен с пользовательским атрибутом

[Serializable] для использования стандартного метода

сериализации, либо можно самостоятельно реализовать интерфейс

ISerializable для задания собственного способа

сериализации. Пользовательские атрибуты и вопросы их использования будут рассмотрены далее.

Обработка ошибок

До сих пор мы не рассматривали обработку ошибок. В COM каждый метод каждого интерфейса (за исключением методов AddRef

и Release интерфейса IUnknown) должен возвращать значение типа HRESULT, говорящее об успехе или неудаче вызова метода и о

причине неудачи. Получатель этого значения должен его обработать. Но у него не всегда есть возможность сделать это.

В .NET используется технология обработки исключений - блоки

try, catch, finally, инициализация исключения - throw.

В нашем распределенном примере при запуске клиента без запуска сервера возникает никем не перехваченная ошибка. Включим

часть кода клиента, где происходит работа с сервером, в блок

try и добавим блоки catch и finally для задания реакции на

ошибки и на выход из блока

try.

using System;

using MyServer;

using System.Runtime.Remoting;

using System.Runtime.Remoting.Channels;

using System.Runtime.Remoting.Channels.Http;

using System.Net;