Добрынин В.Ю. Технологии компонентного программирования
Подождите немного. Документ загружается.
public class MyApp {
public static void Main() {
HttpChannel c = new HttpChannel();
ChannelServices.RegisterChannel(c);
try{
Account a = (Account)Activator.GetObject(
typeof(Account),
"http://localhost:8080/Account",
WellKnownObjectMode.Singleton);
a.Add(5);
Console.WriteLine("Total = {0}", a.Total());
}
catch(WebException e){
Console.WriteLine(e.Message);
}
catch(Exception e){
Console.WriteLine(e.Message);
}
finally{
Console.WriteLine("Bye");
}
}
}
Первый блок catch перехватывает специальное исключение WebException, связанное именно с работой http канала, а второй блок
catch перехватывает все остальные исключения. Независимо от наличия ошибки и ее типа всегда отрабатывает блок finally.
Ниже приведены примеры сообщений, получаемых в консольном окне при запуске клиента до и после запуска сервера.
К
лиент запущен до запуска сервера
>MyApp.exe
The underlying connection was closed: Unable to connect
to the remote server
Bye
>
К
лиент запущен после запуска сервера
>MyApp.exe
Total = 5
Bye
>
Необходимо еще одно дополнительное замечание. Если имеет место цепочка вызовов, то необработанное исключение
поднимается вверх по цепочке вызовов до блока
catch, способного его обработать. Это позволяет сделать обработку в наиболее
удобном месте. Возможна и частичная обработка ошибки на каждом уровне при ее передаче вверх по стеку вызовов.
Синхронизация
Теперь рассмотрим случай двух клиентов, параллельно посылающих некоторые суммы на один и тот же счет, поддерживаемый
нашим сервером.
Вспомним, что в COM использовались апартаменты типа STA для объектов, не допускающих параллельный вызов своих методов,
и типа MTA для потоко-безопасных объектов. В .NET по умолчанию считается, что все объекты являются потоко-безопасными.
Проверим
это, испортив наш сервер для большей наглядности. В локальной переменной метода Add сохраняется текущая
величина счета, после чего текущий поток засыпает на 1 миллисекунду и, проснувшись, делает текущее значение счета равным
сумме значения, сохраненного в локальной переменной, и полученной от клиента величине нового вклада.
Сервер
. . . . .
using System.Threading;
. . . . .
public class Account: MarshalByRefObject, IAccumulator, IAudit{
. . . . .
public void Add(int sum){
int s = _sum;
Thread.Sleep(1);
_sum = s + sum;
}
. . . . .
Клиент посылает на сервер 1000
р
аз по 5 условных единиц и после этого выводит на свою консоль общую отправленную сумму.
К
лиент
. . . . .
int sentTotal = 0;
for (int i = 0; i < 1000; i++){
a.Add(5);
sentTotal +=5;
}
Console.WriteLine("Sent totally by this client = {0}",
sentTotal);
. . . . .
Запустим сервер и затем с небольшим временным интервалом двух клиентов. Каждый из запущенных клиентов по завершении
своей работы выведет на свою консоль следующие строки:
>MyApp.exe
Sent totally by this client = 5000
Bye
>
Несложно написать клиентскую программу, которая обращается к работающему серверу и выводит на свою консоль текущую
величину счета. Здесь для краткости эта программа (
total.exe) не приведена, но для примера приводится результат ее работы
(программа
total была запущена после завершения работы обоих клиентов)
>total.exe
Received by server from all clients = 7240
Bye
>
Здесь естественно возникает вопрос - почему итоговая сумма не равна ожидаемой величине (10000)? Причина кроется в том, что
наш сервер не является потоко-безопасным. При его работе возникают ситуации, когда один поток запомнил текущую сумму
счета и заснул, а тем временем другой поток успел эту сумму обновить. Проснувшись, первый поток работает со старой
величиной счета, не зная об его обновлении вторым потоком. Конкретная величина расхождения суммы на счете с ожидаемыми
10000 зависит от временного интервала между моментами запуска обоих клиентов.
Простое решение проблемы - создать контекст синхронизации, в который и поместить серверный компонент. В этом случае
новый поток блокируется при входе этот контекст, если в
нем исполняется какой-либо другой поток. Для этого достаточно
пометить наш класс
Account атрибутом [Synchronization()] и привязать его к контексту, в котором он будет создаваться. Для
этого класс
Account должен наследовать классу
ContextBoundObject, который в свою очередь является производным от класса MarshalByRefObject.
Ниже приведен полный код сервера, для которого вышеописанных проблем синхронизации больше нет
using System;
using System.Runtime.Remoting;
using System.Runtime.Remoting.Channels;
using System.Runtime.Remoting.Channels.Http;
using System.Threading;
using System.Runtime.Remoting.Contexts;
namespace MyServer {
public interface IAccumulator{
void Add(int sum);
}
public interface IAudit{
int Total();
}
[Synchronization()]
public class Account: ContextBoundObject, IAccumulator, IAudit{
protected int _sum = 0;
public void Add(int sum){
int s = _sum;
Thread.Sleep(1);
_sum = s + sum;
}
public int Total(){
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");
}
}
}
И несколько комментариев. В .NET синхронизацию можно обеспечить либо с помощью критических секций, встраиваемых в код
компонента, либо декларативно с помощью контекста синхронизации. Последнее похоже на использование понятия активности в
COM+.
Привязка объекта к контексту позволяет использовать при работе с этим объектом различные сервисы (например, синхронизации,
поддержки транзакций и т.п.). Но
зато и обращаться к такому объекту извне его контекста можно только через прокси. Однако
это прозрачно для клиента, не нужно создавать и регистрировать какие-либо каналы (при работе в рамках одного домена
приложения). Если объект не привязан к контексту, то он располагается в специальном контексте по умолчанию. К контексту по
умолчанию
имеют прямой доступ все потоки, исполняемые в данном домене приложения.
Набор сервисов, доступных объектам привязанным к контексту, можно расширять вводя новые атрибуты и реализуя перехват
вызовов методов этих объектов. Подробнее эти важные вопросы будут рассмотрены в следующем разделе.
.NET и аспектно-ориентированное программирование
Введение
Говоря про компонентное программирование нельзя не упомянуть про парадигму аспектно-ориентированного программирования
(АОП). Элементы этой парадигмы встречаются в области технологии программирования уже достаточно давно. Это субъектно -
ориентированное программирование ( subject - oriented programming ) [SOP1, SOP2], композиционные фильтры ( composition
filters ) [CF1, CF2], адаптивное программирование ( adaptive programming ) [AP1, AP2]. В наиболее явной форме формулировка
данной парадигмы представлена в работе [AOP1]. Хороший обзор по АОП представлен в диссертации [AOP2]. И
, наконец, связи
между АОП и .NET отражены в статье [AOP3].
С точки зрения АОП в процессе разработки достаточно сложной системы программист решает две ортогональные задачи:
z Разработка компонентов
z Разработка сервисов, поддерживающих взаимодействие компонентов
Такие языки программирования как, например, C++, VB и т.п. ориентированы прежде всего на решение первой задачи. Код
компонента представляется в виде класса, т.е. он хорошо локализован и, следовательно, его легко просматривать, изучать,
модифицировать, повторно использовать. С другой стороны, при программировании процессов, в которые вовлечены различные
объекты
, мы получаем код, в котором элементы, связанные с поддержкой такого процесса, распределены по коду всей системы.
Эти элементы встречаются в коде множества классов, их совокупность в целом не локализована в обозримом сегменте кода. В
результате мы сталкиваемся с проблемой "запутанного" кода (code tangling).
В рамках АОП утверждается, что никакая технология проектирования не
поможет решить данную проблему, если только мы
будем оставаться в рамках языка, ориентированного только на разработку компонентов. Для программирования сервисов,
обеспечивающих взаимодействие объектов, нужны специальные средства, возможно специальные языки.
Понятие аспект в рамках АОП в диссертации [AOP2] определено так: "Некоторая модель является аспектом другой модели, если
она пересекает (crosscuts) ее структуру". Иными словами
понятие аспекта относительно. Если, например, в качестве модели
некоторой системы мы рассматриваем совокупность компонентов, представляющих такие сущности как вкладчик, счет, банк, то
аспектами являются сервисы, обеспечивающие синхронизацию доступа к счету, распределенные транзакции, безопасность. То
есть автоматически выполняемые сервисы, обеспечивающие слаженную, надежную, безопасную работу компонентов.
Итак, согласно парадигме АОП, для программирования
компонентов и аспектов нужны различные, специфические языки
программирования. После этапа кодирования компонентов и аспектов на соответствующих языках выполняется автоматическое
построение оптимизированного для выполнения (но не для просмотра и модификации) кода (например, на C). Этот финальный
процесс называется слиянием ( weaving ).
В рамках COM+ элементы идей АОП присутствуют в виде использования декларативного программирования для задания
сервисов
, услугами которых будут пользоваться компоненты. Сами компоненты разрабатываются на языках, ориентированных на
разработку компонентов (C++, VB). При конфигурировании компонента в COM+ приложении задается некоторый набор
атрибутов, определяющий тот набор сервисов, которыми будет пользоваться данный компонент.
В COM+ набор возможных сервисов и, соответственно, задающих их атрибутов, фиксирован. Программист не может разработать
новый сервис, который можно
было бы декларативно связать с некоторым компонентом, приписав последнему соответствующий
атрибут. Ситуация изменилась в .NET. Хотя и осталась возможность использовать все сервисы из COM+, появилась новая
возможность разработки новых сервисов, подключаемых к компонентам декларативно, посредством определения новых
атрибутов. Весь этот механизм основан на таких понятиях как контекст и пользовательский атрибут.
Прежде чем мы
перейдем к рассмотрению контекстов и атрибутов необходимо заметить, что в документации к .NET отсутствует
информация о ряде важнейших классов и интерфейсов, которые нам предстоит использовать. Указывается, что эти классы и
интерфейсы предназначены для использования самой системой (CLR), и что не предполагается их использование разработчиками
приложений. Тем не менее получить информацию об этих
классах и интерфейсах возможно. Имеются статьи (например, [AOP3]),
код, в которых демонстрируется использование данных классов и интерфейсов.
Важнейшим новым источником информации является опубликованный Microsoft весной 2002 года код объемом около 1.9 млн
строк и документация к нему - Shared Source Common Language Infrastructure (SSCLI). Этот код является одной из возможных
реализаций спецификации языка C# и Common Language Infrastructure (CLI), принятых европейской организацией стандартизации
ECMA в конце 2001 года. .NET Framework является коммерческой реализацией этой же спецификации.
Несмотря на определенные различия между CLR из .NET и SSCLI, код из CLI является полезным источником информации при
изучении .NET. В частности, изучение кода атрибута
SynchronizationAttribute из SSCLI позволяет глубже понять его
семантику, что необходимо для правильного и эффективного использования данного атрибута в .NET.
В последующих разделах данной главы технология работы с контекстами и пользовательскими атрибутами будет
продемонстрирована на простом примере, кторый является некоторым расширением ранее расмотренного примера из
предыдущей главы.
Описание примера
Изучаемый ниже пример разрабатывался с целью демонстрации ряда тонких моментов, связанных с контекстами, потоками и
пользовательскими атрибутами. На основе использования этого примера мы проведем серию экспериментов, которые помогут
прояснить излагаемые вопросы.
Как и в предыдущем разделе консольное клиентское приложение делает вклад на счет, поддерживаемый другим ранее
запущенным консольным серверным приложением. Серверное
приложение содержит три компонента, представляемые классами
Account, Tax и News.
Компонент
Account поддерживает счет, позволяя клиентам сделать вклад (метод Add) и узнать величину текущего счета (метод
Total).
Компоненты
Tax и News представляют соответственно налоговую службу и агенство новостей. Оба компонента получают
уведомления о вкладах на счет (метод
Notify) и выводят соответствующую информацию на консоль.
Компонент
Tax активируется компонентом Account, который добровольно информирует Tax о каждом сделанном вкладе в
процессе выполнения вызова метода
Add. В свою очередь компонент Tax активирует компонент News, которому и передает
полученную от
Account информацию для придания ее гласности. Не полагаясь исключительно на компонент Tax, компонент
Account получает от Tax ссылку на компонент News и самостоятельно напрямую посылает уведомление этому компоненту.
Для демонстрации пользовательских атрибутов, позволяющих задавать набор сервисов, доступных компонентам серверного
приложения, мы будем использовать два атрибута:
z SynchronizationAttribute
Этот атрибут синхронизации реализован в .NET и уже применялся в примере предыдущей главы. Как уже отмечалось
выше, семантика этого атрибута весьма не проста, и для ее полного понимания полезно познакомиться с кодом этого
атрибута, представленным в SSCLI ( файл sscli clr scr bcl system runtime remoting synchronizeddispatch.cs ). Этот код
содержит 1010 строк ( вместе с комментариями ). Мы не будем здесь его разбирать полностью
, однако основные сведения,
полученные при его изучении, будут в данной главе изложены и продемонстрированы в экспериментах.
z MyCallTraceAttribute
Код этого атрибута трассировки вызовов приводится в данной главе. Надо заметить, что атрибуты с семантикой
трассировки вызовов очень популярны среди авторов, пишущих на темы .NET. Приведенный здесь код содержит
фрагменты из ряда опубликованных примеров (в частности, из кода к статье [AOP3]) и используется исключительно в
демонстрационных целях.
Весь код примера содержится в
трех файлах:
z MyApp.cs
Этот файл содержит код консольного клиентского приложения.
z MyServer.cs
Файл содержит код консольного серверного приложения и трех компонентов (
Account, Tax, News).
z MyCallTrace.cs
Этот файл содержит код атрибута трассировки вызовов.
Ниже приводится makefile, который можно использовать для компиляции и сборки клиентского и серверного приложений
all: MyApp MyServer
clean:
@del MyApp.exe MyServer.exe
MyApp: MyApp.exe
MyApp.exe: MyApp.cs MyServer.exe
csc /r:MyServer.exe MyApp.cs
MyServer: MyServer.exe
MyServer.exe: MyServer.cs MyCallTrace.cs
csc MyServer.cs MyCallTrace.cs
Из этого кода видно, что и клиентское, и серверное приложение являются приложениями типа .exe и запускаются в различных
доменах приложений. Для использования этого makefile достаточно запустить
nmake, в результате чего будут получены файлы
MyApp.exe и MyServer.exe.
Серверное приложение
Ниже приводится код из файла MyServer.cs, который является некоторым расширением одноименного файла, расмотренного в
предыдущей главе.
using System;
using System.Runtime.Remoting;
using System.Runtime.Remoting.Channels;
using System.Runtime.Remoting.Channels.Http;
using System.Threading;
using System.Runtime.Remoting.Contexts;
namespace SPbU.AOP_NET {
public interface IAccumulator {
void Add(int sum);
}
public interface IAudit {
int Total();
}
[Synchronization()]
[MyCallTrace("LogFile")]
public class Account: ContextBoundObject,
IAccumulator, IAudit {
private Tax _tax;
private int _sum = 0;
public Account() {
_tax = new Tax();
Console.WriteLine("Account context = " +
Thread.CurrentContext.ContextID + "\n" +
"Account constructor thread = " +
Thread.CurrentThread.GetHashCode() +
" IsPoolThread = " +
Thread.CurrentThread.IsThreadPoolThread);
}
public void Add(int sum){
_sum += sum;
_tax.Notify("new Account operation : +" + sum);
_tax.news.Notify("direct notification from Account");
Console.WriteLine("Account Add thread = " +
Thread.CurrentThread.GetHashCode() +
" IsPoolThread = " +
Thread.CurrentThread.IsThreadPoolThread);
}
public int Total(){
return _sum;
}
}
[Synchronization()]
[MyCallTrace("LogFile")]
public class Tax : ContextBoundObject{
private News _news;
public Tax(){
_news = new News();
Console.WriteLine("Tax context = " +
Thread.CurrentContext.ContextID + "\n" +
"Tax constructor thread = " +
Thread.CurrentThread.GetHashCode() +
" IsPoolThread = " +
Thread.CurrentThread.IsThreadPoolThread);
}
public void Notify(String msg){
Console.WriteLine("Tax notification : " + msg);
Console.WriteLine("Tax Notify thread = " +
Thread.CurrentThread.GetHashCode() +
" IsPoolThread = " +
Thread.CurrentThread.IsThreadPoolThread);
_news.Notify(msg);
}
public News news {
get {
return _news;
}
}
}
[Synchronization()]
[MyCallTrace("LogFile")]
public class News : ContextBoundObject {
public News(){
Console.WriteLine("News context = " +
Thread.CurrentContext.ContextID + "\n" +
"News constructor thread = " +
Thread.CurrentThread.GetHashCode() +
" IsPoolThread = " +
Thread.CurrentThread.IsThreadPoolThread);
}
public void Notify(String msg) {
Console.WriteLine("News notification : " + msg);
Console.WriteLine("News Notify thread = " +
Thread.CurrentThread.GetHashCode() +
" IsPoolThread = " +
Thread.CurrentThread.IsThreadPoolThread);
}
}
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");
}
}
}
Некоторые комментарии:
1. Определяемые в этом коде классы включаются в новое пространство имен -
SPbU.AOP_NET. В этом же пространстве имен
будет определен далее и атрибут трассировки вызовов
MyCallTraceAttribute. При выборе имени пространства имен
использовалась следующая рекомендация - префикс имени должен определять организацию, в которой работает
разработчик. Попутно стоит заметить, что атрибут
SynchronizationAttribute принадлежит пространству имен
System.Runtime.Remoting.Contexts.
2. Классу
Account наряду с атрибутом синхронизации (можно опустить часть "Attribute" при задании имени атрибута)
приписан атрибут трассировки вызовов -
[MyCallTrace("LogFile")]. Здесь аргумент задает имя файла в рабочем каталоге,
в конец которого будут записываться данные о вызовах методов этого класса. Однако трассировка вызовов будет
обеспечиваться не всегда. Это касается только вызовов, сделанных извне контекста, в котором живет объект - экземпляр
данного класса. Трассировка вызовов внутри данного контекста не производится. Понятие контекста и
семантика данного
атрибута будут рассмотрены далее.
3. Код класса
Account претерпел некоторые изменения по сравнению с предыдущей главой:
{ Появилось поле _tax - ссылка на экземпляр класса Tax. Новый экземпляр этого класса активируется в конструкторе
класса
Account с помощью оператора new. В результате при построении на стороне сервера экземпляра класса
Account в этом же домене приложения формируется новый экземпляр класса Tax.
{ В конструкторе класса Account выполняется вывод на консоль сервера идентификатора текущего контекста, т.е.
контекста, в котором создается экземпляр класса
Account. Кроме того на консоль выводится хеш потока, в котором
выполняется конструктор, и логическое значение, равное
true если этот поток выбран системой из пула потоков.
{ При вызове метода Add происходит не только увеличение счета на величину нового вклада, но и вызывается метод
Notify на объекте _tax, которому в качестве аргумента передается строка, сигнализирующая о поступлении нового
вклада на счет.
Кроме того в этом же методе выполняется прямое уведомление компонента
News. Для этого используется ссылка
_tax.news на экземпляр класса News, активированного к этому моменту экземпляром класса Tax. И здесь же на
консоль выводится хеш потока, выполняющего метод
Add, и информация о том, является ли этот поток потоком из
пула потоков. Заметим, что хеш потока является уникальным в системе и может использоваться для идентификации
потоков.
Прежде чем продолжить обсуждение кода сервера, необходимо остановиться на понятии контекста. Это важнейшее понятие
данной главы. Именно механизм контекстов обеспечивает некоторый уровень реализации парадигмы
аспектно-
ориентированного программирования в рамках .NET. Смысл понятия контекста будет разъясняться последовательно в
процессе разбора кода рассматриваемого здесь примера и обсуждения результатов экспериментов с этим кодом. Здесь
обсудим связь между контекстом и доменом приложения.
Все объекты, живущие в некотором домене приложения, разбиваются на непересекающиеся группы. Грубо говоря, в одну
группу попадают объекты
, имеющие сходные запросы на использование сервисов. Все объекты одной группы живут в
одном контексте, а объекты из разных групп живут в разных контекстах.
В каждом домене приложения имеется контекст по умолчанию, в который попадают все объекты, классы которых не
я
вляются производными от класса ContextBoundObject. Таким классам нельзя приписать какой-либо пользовательский
атрибут. Точнее, экземпляры таких классов не могут воспользоваться связанными с этими атрибутами сервисами.
Напротив, экземпляры классов, производных от класса ContextBoundObject, привязаны к конкретным контекстам (кроме
контекста по умолчанию) и могут пользоваться связанными с такими контекстами сервисами.
Однако у объектов, живущих в контексте по умолчанию, имеется одно большое преимущество. Это преимущество состоит
в том, что в любом контексте данного домена приложения можно использовать прямую ссылку на объект, живущий в
контексте по
умолчанию. Если же вызывается объект из какого-либо другого контекста и этот вызов пересекает границу
контекста, то вызывающая сторона использует прокси для вызываемого объекта, сам вызов преобразуется в прокси в
сообщение, которое уже в вызываемом контексте вновь преобразуется в вызов, который и исполняется.
Очевидно, что описанный здесь механизм приводит к значительным
накладным расходам. Однако именно при
использовании такого сложного механизма появляется возможность перехвата сообщений, кодирующих вызовы объектов,
привязанных к контекстам. После перехвата вызова можно выполнить некоторый сервис. Аналагичную процедуру можно
выполнять, перехватывая результаты, возвращаемые вызывающей стороне.
Теперь продолжим обсуждение кода сервера.
4. Класс
Tax ( как и класс Account) привязан к контексту (он наследует классу ContextBoundObject). Это дает возможность
экземплярам данного класса использовать сервисы синхронизации и трассировки вызовов (последнее верно только для
вызовов, приходящих извне данного контекста). Именно для этого классу Tax приписаны атрибуты синхронизации и
трассировки вызовов.
Дополнительные комментарии, касающиеся класса
Tax:
{ В конструкторе класса Tax активируется новый экземпляр класса News, ссылка на который запоминается в поле _news.
Для доступа к этой ссылке предусмотрено публичное свойство
news (только для чтения).
{ При выполнении конструктора класса Tax на консоль сервера выводится информация об идентификаторе контекста, в
котором будет жить новый объект, хеш текущего потока и его тип (поток из пула потоков или нет). Эти данные будут
использованы при проведении экспериментов.
{ Метод Notify класса Tax выводит на консоль полученное уведомление и в свою очередь отсылает полученное
уведомление экземпляру класса
News. Здесь же на консоль выводится хеш текущего потока и его тип.
5. Определение класса
News во многом похоже на определение класса Tax. Достаточно только отметить, что этот класс
является последним в цепочке рассылки уведомлений, что приводит к упрощению кода.
6. Класс
AccountApp содержит функцию Main и определяет консольное серверное приложение. Этот класс не претерпел
никаких изменений по сравнению с соответствующим классом, описанным в предыдущей главе.
Атрибут трассировки вызовов
Прежде чем привести код этого атрибута, вернемся к понятию контекста. Контекст формируется только тогда, когда это
необходимо, т.е. тогда, когда появляется первый объект, который будет жить в этом контексте.
Необходимость создания нового контекста определяется в результате сопоставления требований к сервисам со стороны нового
объекта, и наличных сервисов, доступных в старом
контексте (в контексте, из которого был сделан запрос на формирование
нового объекта). Если старый контекст удовлетворяет требованиям нового объекта, то этот новый объект размещается в старом
контексте и получает возможность использовать связанные с ним сервисы. В противном случае создается новый контекст, с
которым связывается некоторый набор сервисов, запрашиваемых новым объектом.
Связь сервиса с контекстом осуществляется путем задания соответствующего свойства контекста для данного контекста.
Каждое свойство контекста имеет имя и содержит ссылку на некоторый объект, реализующий интерфейс
IContextProperty.
Любой объект в данном контексте может по имени свойства получить доступ к соответствующему объекту-свойству и явно
пользоваться всеми его возможностями (например, вызывать его методы). Такой способ явного использования контекста не очень
интересен, т.к. он предполагает тесную связь между кодом компонента и кодом аспекта (сервиса, доступного через свойство
контекста).
При использовании чисто декларативного способа связывания компонента и аспекта необходимо обеспечить неявное
связывание компонента с сервисом, когда в коде компонента нет никакого упоминания этого сервиса. Этого можно достигнуть за
счет использования понятия перехвата.
Как уже упоминалось ранее, в случае пересечения вызовом границы контекста (кроме контекста по умолчанию), прокси на
вызывающей стороне
преобразует вызов в сообщение (объект, реализующий интерфейс IMessage), которое пройдя через цепочку
перехватчиков (объектов, реализующих интерфейс IMessageSink), в вызываемом контексте вновь преобразуется в вызов, который
исполняется соответствующим объектом. Результат отправляется вызывающей стороне через ту же цепочку перехватчиков.
Каждое свойство контекста может встроить в эту цепочку перехватчиков собственный перехватчик, что и создает возможность
неявного вызова нужного сервиса как до, так и после каждого вызова соответствующего объекта. Для этого объект-свойство,
приписаваемый контексту, должен реализовать какие-либо из трех интерфейсов:
IContributeObjectSink,
IContributeServerContextSink, IContributeClientContextSink. Выбор одного из этих интерфейсов определяет ту цепочку
перехватчиков, в конец которой будет добавлен новый перехватчик. На самом деле в контексте может существовать несколько
цепочек перехватчиков:
z Одна цепочка перехватчиков, перехватывающих все вызовы поступающие ко всем объектам, живущим в данном контексте.
Для встраивания перехватчика в эту цепочку объект-свойство контекста должен реализовать интерфейс
IContributeServerContextSink.
z По одной цепочке к каждому объекту, живущему в контексте. В эту цепочку вызов попадает пройдя по цепочке общей для
всего контекста. Для встраивания перехватчика в эту специфичную для объекта цепочку объект-свойство должен
р
еализовать интерфейс
IContributeObjectSink.
z Одна цепочка для всех вызовов, которые объекты контекста делают за пределы данного контекста. Для встраивания
перехватчика в эту цепочку объект-свойство должен реализовать интерфейс
IContributeClientContextSink.
После этих вводных замечаний о механизме работы атрибута и контекста перейдем к коду атрибута
MyCallTraceAttribute и к
комментариям к этому коду.
using System;
using System.IO;
using System.Threading;
using System.Runtime.Remoting.Messaging;
using System.Runtime.Remoting.Contexts;
using System.Runtime.Remoting.Activation;
using System.Runtime.CompilerServices;
namespace SPbU.AOP_NET{
[AttributeUsage(AttributeTargets.Class)]
public class MyCallTraceAttribute : ContextAttribute,
IContributeServerContextSink {
private const String PROPERTY_NAME = "MyCallTrace";
private String _logFileName = null;
public MyCallTraceAttribute(String logFileName) :
base(PROPERTY_NAME) {
if (logFileName == null){
throw new ArgumentNullException("logFileName");
}
_logFileName = logFileName;
}
public override bool IsContextOK(Context ctx,
IConstructionCallMessage msg) {
if (ctx == null)
throw new ArgumentNullException("ctx");
if (msg == null)
throw new ArgumentNullException("msg");
MyCallTraceAttribute property =
(MyCallTraceAttribute)ctx.GetProperty(PROPERTY_NAME);
if ((property != null) &&
(property._logFileName == _logFileName))
return true;
else
return false;
}
public override void GetPropertiesForNewContext(
IConstructionCallMessage ctorMsg) {
ctorMsg.ContextProperties.Add((IContextProperty)this);
}
public virtual IMessageSink GetServerContextSink(
IMessageSink nextSink) {
MyCallTraceServerContextSink propertySink =
new MyCallTraceServerContextSink(this, nextSink);
return (IMessageSink)propertySink;
}
[MethodImpl(MethodImplOptions.Synchronized)]
internal void LogMessage(String msg){
StreamWriter logFile = null;
while (logFile == null) {
logFile = File.AppendText(_logFileName);
}
logFile.WriteLine(msg);
logFile.Close();
}
}
internal class MyCallTraceServerContextSink : IMessageSink {
internal IMessageSink _nextSink;
internal MyCallTraceAttribute _property;
internal IMessage _replyMsg;
internal MyCallTraceServerContextSink(
MyCallTraceAttribute property, IMessageSink nextSink) {
_property = property;
_nextSink = nextSink;
_replyMsg = null;
}
public virtual IMessage SyncProcessMessage(IMessage reqMsg) {
if (reqMsg is IMethodMessage) {
IMethodMessage call = reqMsg as IMethodMessage;
lock(_property){
_property.LogMessage("===" + call.TypeName);
_property.LogMessage("\n" + call.MethodName +
" \n\t <<<IN>>> parameters: (");
for (int i = 0; i < call.ArgCount; i++) {
if (i > 0 ) _property.LogMessage(", ");
_property.LogMessage(call.GetArgName(i) +
"= " + call.GetArg(i));
}
_property.LogMessage(")\n");
}
}
_replyMsg = _nextSink.SyncProcessMessage(reqMsg);
if (_replyMsg is IMethodReturnMessage){
IMethodReturnMessage retMsg =
(IMethodReturnMessage) _replyMsg;
Exception e = retMsg.Exception;
if (e != null) {
Console.WriteLine(e.Message);
return _replyMsg;
}
lock(_property) {
_property.LogMessage("===" + retMsg.TypeName);
_property.LogMessage("\n" + retMsg.MethodName +
" \n\t <<<OUT>>> parameters: (");
for (int i = 0; i < retMsg.OutArgCount; i++) {
if ( i > 0 ) _property.LogMessage(", ");
_property.LogMessage(retMsg.GetOutArgName(i) +
" = " + retMsg.GetOutArg(i));
}
_property.LogMessage(")\n");
}
}
return _replyMsg;
}
public virtual IMessageCtrl AsyncProcessMessage(IMessage msg,
IMessageSink replySink){
throw new InvalidOperationException();
}
public IMessageSink NextSink {
get {
return _nextSink;
}
}
}
}
Комментарии к коду:
1. Данный код содержит определения двух классов:
{ MyCallTraceAttribute
Этот публичный класс доступен всем приложениям, имеющим доступ к сборке
MyServer.exe
{ MyCallTraceServerContextSink
Этот класс является внутренним (internal) для сборки
MyServer.exe и не доступен за ее пределами.
2. Классу
MyCallTraceAttribute приписан атрибут
[AttributeUsage(AttributeTargets.Class)]. Данный атрибут используется при определении пользовательских атрибутов
для задания элементов, которым может быть приписан данный атрибут. В данном случае атрибут
MyCallTraceAttribute
можно приписать только классу (но нельзя приписать, например, какому-то методу).
3. Комментарии к коду класса
MyCallTraceAttribute:
{ Класс MyCallTraceAttribute является производным классом от класса ContextAttribute и реализует интерфейс
IContributeServerContextSink. В свою очередь класс
ContextAttribute реализует интерфейсы IContextProperty и
IContextAttribute.
Реализация интерфейсов
IContextProperty и IContextAttribute обеспечивает выбор контекста для размещения
активируемого объекта (в старом или в новом контексте), а в случае формирования нового контекста - назначение ему
свойств, которые объект может вызывать в своем коде явно.
Реализация интерфейса
IContributeServerContextSink позволяет включить в конец цепочки перехватчиков,
которые перехватывают все входящие в контекст вызовы, новый перехватчик. Это позволяет декларативно связать
некоторый класс с некоторым автоматическим сервисом, что и является реализацией идей аспектно-
ориентированного программирования.
{ Константа PROPERTY_NAME будет использована для задания имени свойству контекста. Каждое свойство контекста
имеет имя и для любого заданного контекста и имени можно определить - содержит ли данный контекст свойство с
данным именем. Эта возможность используется при выяснении пригодности заданного контекста как среды для
жизни некоторого объекта с определенными требованиями к наличию автоматических сервисов.
{ Поле _logFileName используется свойством контекста для хранения имени файла, в который надо записывать данные
о перехваченных вызовах.
{ Конструктор атрибута принимает в качестве аргумента имя файла, которое и сохраняется в поле _logFileName. Если
имя не задано, генерируется соответствующее исключение. В начале работы конструктора вызывается конструктор
базового класса
ContextAttribute, которому в качестве аргумента передается имя данного свойства контекста ( MyCallTrace ).
{ Публичный виртуальный метод IsContextOK объявлен в интерфейсе IContextAttribute. Именно этот метод
ответственен за определение пригодности заданного контекста
_ctx (первый аргумент) для жизни объекта,
требования которого заданы в сообщении
msg (второй аргумент).
Сообщение
msg должно быть ссылкой на объект, реализующий интерфейс IConstructionCallMessage. Это
сообщение представляет запрос на создание некоторого объекта. Тут нужно напомнить, что в .NET удаленные
объекты активируются либо сервером, либо клиентом. Сообщение типа IConstructionCallMessage посылается от
клиента на сервер именно во втором случае. Для этого клиент либо вызывает
new, и тогда все требования
относительно активации объекта берутся из конфигурационного файла, либо вызывает
Activator.CreateInstance и
передает все необходимые данные в аргументах. Это сообщение приходит на сервер, где активатор
Activator его его
обрабатывает и возвращает клиенту сообщение типа
IConstructionReturnMessage. Последнее содержит
информацию (
ObjRef), достаточную для построения прокси к активируемому объекту.
Так как при наличии нескольких контекстов вызывающая сторона также получает прокси на объект, активированный
в другом контексте, то описанный обмен сообщениями выполняется и в локальном случае при вызове, пересекающем
границу контекста.
Базовая реализация метода
IsContextOK в классе
ContextAttribute (согласно коду из SSCLI) возвращает true, если новый объект не привязан к контексту
(
IsContextful == false) или у контекста ctx имеется свойство, имя которого совпадает с именем данного свойства.
В остальных случаях возвращается
false.
В классе
MyCallTraceAttribute виртуальный метод IsContextOK переопределяется (overide). Прежде всего
генерируется исключение, если не задан контекст
ctx или сообщение msg. Далее делается попытка получить в
контексте
ctx ссылку на его свойство с именем, хранящемся в константе PROPERTY_NAME, типа
MyCallTraceAttribute. Если такое свойство контекста находится, и его поле _logFileName хранит то же имя файла,
что и текущее свойство, то контекст
ctx признается подходящим для активации в нем экземпляра класса с атрибутом
[MyCallTrace(x)], где x - строка, равная строке, хранящейся в _logFileName. В противном случае система
выполнения (CLR) создаст новый контекст для активации в нем этого объекта.
Заметим, что при наличии нескольких атрибутов, приписанных классу, пригодность старого контекста для активации
в нем нового экземпляра этого класса считается установленной, если вызовы метода
IsContextOK для каждого
атрибута возвратили
true.
{ Виртуальный метод GetPropertiesForNewContext объявлен в интерфейсе IContextAttribute. В качестве аргумента
этот метод принимает сообщение
ctorMsg типа IConstructionCallMessage. Данный метод вызывается средой
выполнения CLR если контекст, из которого был сделан запрос на активацию объекта, не удовлетворяет его
требованиям (вызов IsContextOK вернул false). Здесь мы включаем в сообщение ctorMsg ссылку на объект, который
будет играть роль нового свойства контекста -
(IContextProperty)this. Благодаря этой ссылке все объекты, которые будут жить в новом контексте, смогут
пользоваться данным свойством контекста, вызывая явно в своем коде его методы и свойства.
{ Метод GetServerContextSink объявлен в интерфейсе
IContributeServerContextSink и не имеет реализации в классе ContextAttribute. Этот метод должен вернуть
ссылку на объект, реализующий интерфейс
IMessageSink, т.е. на перехватчик, который будет подключен в конец
существующей цепочки перехватчиков, через которую идут все вызовы в данный контекст. Единственным