Симон Робинсон - C# для профессионалов. Том II

// отменить подписку на событие

obj.Status -= new StatusEvent(sink.StatusHandler);

obj.LongWorking(5000);

Console.WriteLine("Hit to exit");

Console.ReadLine();

}

}

}

Конфигурационный файл для клиента — client.exe.configявляется почти таким же конфигурационным файлом, как и для активированных клиентом объектов. Различие можно найти в определении номера порта для канала. Поскольку сервер должен соединяться с клиентом через известный порт, то необходимо определить номер порта для канала как атрибут элемента . Не требуется определять раздел для класса EventSink, так как экземпляр этого класса будет создаваться клиентом локально с помощью оператора new. Сервер не получает доступ к этому объекту по его имени, вместо этого он получит маршализированную ссылку на экземпляр:

Мы видим результирующий вывод на сервере: конструктор удаленного объекта вызывается один раз, так как имеется активированный клиентом объект. Затем происходит вызов метода LongWorking()и порождение события на клиенте. Следующий запуск метода LongWorking()не порождает событий, так как клиент уже отменил регистрацию своего интереса к событию:

В выводе клиента видно, что события достигают его по сети:

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

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

Можно присвоить данные контексту вызова с помощью метода CallContext.SetData(). Класс с объекта, который используется в качестве данных для метода SetData(), должен реализовать интерфейс ILogicalThreadAffinative. Эти данные можно получить снова в том же логическом потоке выполнения (но, возможно, в другом физического потоке выполнения) с помощью CallContext.GetData().

Для данных контекста вызова здесь создается новая библиотека классов C# с вновь созданным классом CallContextData. Этот класс будет использоваться для передачи некоторых данных от клиента серверу с каждым вызовом метода. Класс, который передается с контекстом вызова, должен реализовать интерфейс System.Runtime.Remoting.Messaging.ILogicalThreadAffinative. Этот интерфейс не имеет метода, это просто отметка для среды выполнения, определяющая, что экземпляры этого класса перемещаются вместе с логическим потока выполнения. Класс CallContextDataтакже помечается атрибутом Serializable, чтобы он мог передаваться по каналу:

using System;

using System.Runtime.Remoting.Messaging

namespace Wrox.ProfessionalCSharp {

[Serializable]

public class CallContextData : ILogicalThreadAffinative {

public CallContextData() { }

public string Data {

get {

return data;

}

set {

data = value;

}

}

protected string data;

}

}

В классе Helloметод Greeting()изменяется так, чтобы можно было получить доступ к контексту вызова. Для использования класса CallContextDataнеобходимо сослаться на созданную ранее сборку CallContextData.dll. Чтобы работать с классом CallContext, должно быть открыто пространство имен System.Runtime.Remoting.Messaging:

public string Greeting(string name) {

Console.WriteLine("Greeting started");

CallContextData cookie = (CallContextData)CallContext.GetData("mycookie");

if (cookie ! = null) {

Console.WriteLine("Cookie: " + cookie.Data);

}

Console.WriteLine("Greeting finished");

return "Hello, " + name;

}

В клиентском коде передается информация контекста вызова:

CallContextData cookie = new CallContextData();

cookie.Data = "information for the server";

CallContext.SetData("mycookie", cookie);

for (int i=0; i< 5; i++) {

Console.WriteLine(obj.Greeting("Christian"));

}

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

В этой главе мы видели, что .NET Remoting использовать очень легко. Удаленный объект должен просто наследовать из объекта MarshalByRefObject. В серверном приложении требуется только один метод для загрузки конфигурационного файла, чтобы настроить и запустить каналы и удаленные объекты. На клиенте загружается конфигурационный файл и используется оператор new для создания экземпляра удаленного объекта.

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

Наравне с этими приемами применяют много механизмов из других частей .NET Framework, которые также работают с .NET Remoting, такие как вызов асинхронных методов, выполнение обратных вызовов с помощью ключевых слов delegateи eventи т. д.

Таким образом, использование .NET Remoting является очень простым, архитектура достаточно гибкой и по желанию расширяемой. Можно использовать каналы HTTP и TCP, которые также расширяются, или написать новые каналы с самого начала. Существуют форматтер SOAP и двоичный форматтер, но легко можно использовать свой собственный. Также имеется много точек перехвата, где возможно добавление в классы специальной функциональности, которая доставляется с помощью .NET Framework.

В главе 22 рассматривается работа в сети, глава 23 охватывает работу с серверами с помощью .NET Remoting. Описанные серверные процессы запускаются вручную. Однако программы должны начинать работать автоматически во время запуска машины. Здесь на помощь приходят службы Windows.