Добавить в цитаты Настройки чтения

Страница 218 из 372

♦ Метод GetServerContextSink объявлен в интерфейсе IContributeServerContextSink и не имеет реализации в классе ContextAttribute. Этот метод должен вернуть ссылку на объект, реализующий интерфейс IMessageSink, т. е. на перехватчик, который будет подключен в конец существующей цепочки перехватчиков, через которую идут все вызовы в данный контекст. Единственным аргументом является ссылка nextSink на конец имеющейся в данный момент цепочки перехватчиков. В данной реализации этого метода формируется экземпляр класса MyCallTraceServerContextSink, который будет прокомментирован ниже.

Ссылка на этот экземпляр (новый перехватчик) и возвращается как результат вызова GetServerContextSink.

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

♦ Последний метод (LogMessage) класса MyCallTraceAttribute является внутренним для сборки и будет вызываться из класса MyCallTraceServerContextSink. Данный метод обеспечивает запись переданной в качестве аргумента строки в конец файла с именем, хранящемся в поле _logFileName свойства типа MyCallTraceAttribute с именем MyCallTrace текущего контекста. Объекты, живущие в данном контексте, могут вызывать этот метод явно в своем коде, получив ссылку на это свойство контекста по его имени. Однако в данном примере будет продемонстрировано использование свойства контекста в стиле аспектно-ориентированного программирования. Поэтому метод LogMessage будет в нашем случае вызываться перехватчиком, а не самим объектом, получившим вызов.

Реализации метода LogMessage весьма не эффективна. При каждом вызове этого метода файл открывается для записи в конец, производится запись и файл закрывается. Для обеспечения потокобезопасности весь метод включается в критическую секцию, препятствующую параллельному выполнению этого метода несколькими потоками. Для этого методу приписан атрибут [MethodImpl(MethodImplOptions. Synchronized)].

Цикл

while (logFile == null) {

           logFile = File. AppendText(_logFileName);

}

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

4. Комментарий К коду класса MyCallTraceContextSink

♦ Данный внутренний класс реализует интерфейс IMessageSink и, следовательно, реализует некоторый перехватчик,

♦ Поле _nextsink будет хранить ссылку на следующий перехватчик в той цепи перехватчиков, в конец которой будет добавлен данный перехватчик,

♦ Поле _property предназначено для хранения ссылки на свойство контекста типа MyCallTraceAttribute. Перехватчик порождается благодаря методу GetPropertiesForNewContext, реализованного этим свойством контекста. Однако сейчас нам это свойство важно тем, что именно его метод LogMessage будет вызываться перехватчиком при перехвате нового вызова,

♦ Поле _replyMsg типа IMessage будет хранить ответ вызванного метода, полученный данным перехватчиком от перехватчика nextsink. о Конструктор данного класса принимает два аргумента:

— property

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

— nextSink

Это ссылка на следующий перехватчик в цепи перехватчиков.

Данные значения присваиваются соответственно полям _property и _nextsink.

♦ Виртуальный метод SyncProcessMessage объявлен в интерфейсе IMessageSink. Этот метод реализует обработку синхронных вызовов, т. е. вызовов, после инициализации которых клиенты блокируются до получения ответа.

Единственный аргумент данного метода — сообщение reqMsg (request message), содержащее вызов, полученный от клиента и уже, возможно, обработанный перехватчиками, находящимися в цепочке ближе к клиенту.

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

Обработка вызова состоит в том, что перехватчик выводит с помощью LogMessage информацию о типе, о методе и о входных ([IN]) аргументах. Пример (слегка отредактированный для удобства просмотра) выводимой информации в случае вызова метода Notify экземпляра класса News приведен ниже:





===SPbU.AOP_NET.News, MyServer, Version = 0.0.0.0,

     Culture = neutral, PublicKeyToken = null

Notify

     <<<IN>>> parameters: {

msg = new Account operation: +5)

}

В процессе обработки перехваченного вызова сообщение reqMsg приводится к типу IMethodMessage и блокируется свойство контекста _property. Эта блокировка позволит при записи информации в файл посредством вызова LogMessage группировать все строки, относящиеся к одному вызову, вместе, т. е. не допускать в файле с именем _logFileName чередования строк, относящихся к различным вызовам.

После завершения обработки перехваченного вызова данный перехватчик передает неизменное сообщение reqMsg следующему в цепочке перехватчику (перехватчику, находящемуся ближе к серверу). Для этого вызывается метод SyncProcessMessage перехватчика _nextSink.

После получения сообщения _replyMsg, содержащего ответ сервера (возможно обработанный перехватчиками, находящимися ближе к серверу), наш перехватчик в свою очередь обрабатывает это сообщение, если его тип есть IMethodReturnMessage. В процессе обработки полученное сообщение приводится к типу IMethodReturnMessage, после чего проверяется, не было ли в процессе выполнения данного вызова инициировано неперехваченное ранее исключение.

При наличии неперехваченного исключения на консоль сервера выводится соответствующее сообщение и метод возвращает полученный ответ без какой-либо обработки. В противном случае выполняется процесс, аналогичный описанному ранее (обработка вызова). Блокируется свойство контекста _property и посредством вызова метода _property.LogMessage выводится информация о типе, о вызванном методе, список выходных [out] аргументов. Ниже приведен пример для ответа на вызов метода Notify класса News:

===SPbU.AOP_NET.News, MyServer, Version = 0.0.0.0,

     Culture = neutral, PublicKeyToken = null

Notify

      <<<OUT>>> parameters: {

}

И, наконец, возвращается без изменений сообщение _repiyMsg.

Виртуальный метод AsyncProcessMessage объявлен в интерфейсе IMessageSink и обязательно должен быть реализован в данном классе. Этот метод предназначен для обработки асинхронных вызовов, т. е. вызовов, после инициализации которых клиент не блокируется, а продолжает свою работу.

Данный метод имеет два аргумента:

— msg — сообщение типа IMessage, содержащее вызов.

— repiysink — ссылка на перехватчик, на который надо отсылать результат. Именно этот перехватчик ответственен за уведомление клиента о полученном результате.

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

♦ Свойство (только для чтения) NextSink также объявлено в интерфейсе IMessageSink и должно быть реализовано в данном классе. Здесь просто возвращается значение _nextsink.