Сервер в процессе клиента
Рассмотрим в качестве примера процесс построения и использования сервера, который в рамках COM-терминологии получил бы классификацию "сервер в процессе клиента", т. к. он будет исполняться в адресном процессе клиента. Код представлен на С#.
Сервер
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();
Methodlnfо[] Methods = iAuditType.GetMethods();
foreach (MethodInfо Method in Methods)!
Console.WriteLine(Method.ToString());
}
}
}
В данном примере сервер реализован классом Account. Этот класс реализует два интерфейса:
• IAccumulator
Этот интерфейс позволяет клиенту отправлять на счет, поддерживаемый сервером, некоторую сумму (метод Add)
• IAudit
Данный интерфейс позволяет клиенту узнать текущее состояние счета (метод Total)
И интерфейсы, и реализующий их класс Account определяются в рамках одного пространства имен MyServer.
Стоит еще обратить внимание на то, что метод Total не только возвращает текущую сумму на счете, но и выводит на консоль имя домена приложения, в котором выполняется сервер. Тут необходимы дополнительные пояснения. Управляемый код, порождаемый компилятором с C# и использующий все сервисы CLR, является типо-безопасным кодом, который в процессе своего выполнения не может повредить данные, к которым он не должен иметь доступа. Это позволяет в рамках одного процесса организовать несколько логических процессов — доменов приложений (Application Domain), которые делят одно адресное пространство и границу между которыми может пересекать поток. Каждое приложение работает в рамках одного домена приложения. За счет "легковестности" доменов приложений, их использование более эффективно, чем использование для каждого приложения отдельного процесса. Выводимая на консоль информация об имени домена приложения позволит нам проверить, что и клиент и сервер действительно выполняются в рамках одного домена приложения.
Теперь обратимся к клиенту. Используется пространство имен MyServer, в котором определен класс Account. Кроме того, используется пространство имен System. Reflection. В этом пространстве определены классы, обеспечивающие механизм рефлексии, т. е. доступ к метаданным.
Клиентское приложение является консольным приложением. Функция Main обеспечивает точку входа. Оператор new обеспечивает построение экземпляра класса Account. При этом нет необходимости предварительно регистрировать сервер в реестре и при его активации задавать соответствующий CLSID. Нет и никаких фабрик классов.
Во-первых, теперь нет нужды в методе QueryInterface. Оператор as позволяет безопасно привести ссылку на объект к ссылке на любой реализуемый им интерфейс. Если полученная ссылка на интерфейс IAccumulator не равна null, то это означает, что класс Account действительно реализует интерфейс IAccumulator и клиент может отправить на счет две суммы (3 и 5), используя метод Add.
Теперь, имея ссылку на интерфейс IAccumulator, можно перейти к ссылке на интерфейс IAudit. В случае реализации этого интерфейса вызывается его метод Total и на консоль выводится сумма счета и имя домена приложения, в котором выполняется клиент.
Во-вторых, кардинально меняется подход к управлению памятью. Заметим, что мы не освободили память, отведенную под экземпляр класса Account. В СОМ управление временем жизни объекта выполняется с помощью подсчета числа сделанных на него ссылок. Когда число ссылок становится равным 0, объект вызывает собственный деструктор.
Этот механизм имеет много недостатков. Тут и ошибки при подсчете сделанных ссылок (клиент должен вызывать методы AddRef и Release интерфейса IUnknown соответственно при получении новой ссылки на объект и при ее освобождении), и возможность появления циклических ссылок, при наличии которых счетчик числа ссылок на некоторые объекты никогда не обратится в 0. Во всех случаях возникает утечка памяти, весьма нежелательная в случае долгоживущих серверных приложений.
В.NET используется автоматическое управление выделением и освобождением памяти. Менеджер кучи быстро выделяет память для вновь создаваемых объектов благодаря наличию указателя на начало непрерывного свободного пространства в куче. Если этот указатель приближается к границе кучи, и менеджер не может выделить память по очередному запросу, выполняется дорогостоящий процесс освобождения более не используемой памяти. Сборщик мусора находит ссылки на все используемые объекты, и перемещает их образы в куче к ее началу, модифицируя все адреса перемещаемых объектов в данных и в коде. Вся остальная часть кучи после последнего используемого объекта считается свободной.
Конечно, со сборкой мусора связаны свои проблемы:
• Недетерминированность
Момент начала сборки мусора заранее как правило не известен. Если объект связывает ценные ресурсы (открытые файлы, соединения с базой данных), то клиент должен явно вызвать метод Dispose, в котором объект должен реализовать освобождение упомянутых и других ценных ресурсов не дожидаясь начала работы сборщика мусора.
Если надежд на клиента мало, класс должен реализовать метод Finalize, в котором также должно выполняться освобождение ресурсов. В отличие от метода Dispose, метод Finalize вызывается автоматически во время сборки мусора до уничтожения объекта.
• Распределенная сборка мусора
Сборщик мусора не имеет доступа к удаленным объектам. Их освобождение регулируется другим механизмом, т. н. лизингом (leasing).
Последняя часть кода клиента демонстрирует применение механизма рефлексии. Цель — вывести на консоль сигнатуры всех методов, которые доступны через интерфейс IAudit. Заметим, что это будут не только все методы, реализованные в классе Account, но и все методы, реализованные в корневом классе System.Object, от которого неявно наследуют все классы в .NET, в том числе и класс Account.
Наследуемый метод GetType позволяет получить ссылку на объект типа Tуре, содержащий всю нужную информацию. Далее формируется массив всех доступных методов и в цикле на консоль выводится сигнатура каждого доступного метода.
