Напомним, что слой удаленного взаимодействия .NET различает два вида MBR-объектов: WKO (активизируются сервером) и САО (активизируются клиентом). К тому же, WKO-тип может быть активизирован либо как синглет, либо как объект одиночного вызова. Используя функциональные возможности типа RemotingConfiguration, вы можете динамически получить такую информацию в среде выполнения. Например, если добавить в метод Main() приложения SimpleRemoteObjectServer следующие строки программного кода:
static void Main(string[] args) {
…
// Установка понятного имени для данного приложения сервера.
RemotingConfiguration.ApplicationName = "Первое серверное приложение";
Console.WriteLine("Имя приложения: {0}", RemotingConfiguration.ApplicationName);
// Получение массива типов WellKnownServiceTypeEntry,
// представляющих зарегистрированные WKO-объекты.
WellKnownServiceTypeEntry[] WKOs = RemotingConfiguration.GetRegisteredWellKnownServiceTypes();
// Вывод информации.
foreach(WellKnownServiceTypeEntry wko in WKOs) {
Console.WriteLine("Имя блока, содержащего WKO: {0}", wko.AssemblyName);
Console.WriteLine("URL данного WKO: {0}", wko.ObjectUri);
Console.WriteLine("Тип WKO: {0}", wko.ObjectType);
Console.WriteLine("Режим активизации WKO: {0}", wko.Mоde);
}
}
то вы должны увидеть список всех WKO-типов, зарегистрированных доменом приложения сервера. Выполнив цикл по всем элементам массива типов WellKnownServiceTypeEntry, можно выяснить характеристики каждого из WKO-объектов. Поскольку ваше серверное приложение регистрирует только один тип (SimpleRemotingAsm.RemoteMessageObject), вы получите вывод, показанный на рис. 18.5.
Рис. 18.5. Статистика сервера
Другим важным методом типа RemotingConfiguration является метод Configure(). Вскоре вы сможете убедиться, что этот статический член позволяет доменам приложений клиента и сервера использовать файлы конфигурации удаленного взаимодействия.
Снова о режиме активизации WKO-типов
Напомним, что WKO-типы можно настроить для работы либо в режиме синглета, либо в режиме объекта одиночного вызова. В настоящее время ваше серверное приложение регистрирует WKO-тип с использованием семантики активизации синглета.
// Синглеты могут обслуживать множество клиентов.
RemotingConfiguration.RegisterWellKnownServiceType(typeof(SimpleRemotingAsm.RemoteMessageObject), "RemoteMsgObj.soap", WellKnownObjectMode.Singleton);
Снова обратим внимание на то, что WKO-синглеты могут получать запросы от множества клиентов. Поэтому синглеты связаны с удаленными клиентами отношением "один ко множеству". Чтобы проверить это непосредственно, запустите приложение сервера (если оно в настоящий момент еще не выполняется) и три отдельных приложения клиента. Если посмотреть на вывод сервера, вы обнаружите там только один вызов заданного по умолчанию конструктора RemoteMessageObject.
Чтобы рассмотреть поведение объектов одиночного вызова, измените серверное приложение так, чтобы в нем регистрировался WKO-объект, поддерживающий активизацию одиночного вызова.
// WKO-типы одиночного вызова связаны с клиентом
// отношением "один к одному".
RemotingConfiguration.RegisterWellKnownServiceType(typeof(SimpleRemotingAsm.RemoteMessageObject), "RemoteMsgObj.soap", WellKnownObjectMode.SingleCall);
После перекомпиляции и запуска серверного приложения снова запустите три клиента. На этот раз вы увидите, что для каждого запроса клиента будет создан новый RemoteMessageObject. Итак, если вы хотите сделать данные состояния общими для множества удаленных клиентов, то активизация синглета оказывается единственным подходящим вариантом, поскольку тогда все клиенты "общаются" с единственным экземпляром удаленного объекта.
Исходный код. Проекты SimpleRemotingAsm, SimpleRemoteObjectServer и SimpleRemoteObjectClient размещены в подкаталоге, соответствующем главе 18.
Установка сервера на удаленной машине
К этому моменту вы реализовали возможность пересечения границ приложения и процесса на одной машине. Если у вас есть возможность связи с другой машиной, вы можете расширить свой пример так, чтобы клиент мог взаимодействовать с типом RemoteMessageObject через границы машин. Для этого необходимо сделать следующее.
1. На машине сервера создайте и откройте для доступа папку, в которой будут содержаться компоновочные блоки серверной стороны,
2. Скопируйте компоновочные блоки SimpleRemoteObjeсtServer.exe и SimpleRemotingAsm.dll в эту папку.
3. Откройте проект SimpleRemoteObjectClient и измените URL активизации в соответствии с именем удаленной машины, например:
// Получение агента для удаленного объекта.
object remoteObj = Activator.GetObject(typeof(SimpleRemotingAsm.RemoteMessageObject), "httр://ИмяУдаленнойМашины:32469/RemoteMsgObj.soap");
4. Запустите приложение SimpleRemoteObjectServer.exe на машине сервера.
5. Запустите приложение SimpleRemoteObjectClient.exe на машине клиента.
6. Откиньтесь на спинку кресла, расслабьтесь и улыбнитесь.
Замечание. Вместо понятного имени Машины URL активизации может указывать ее IP-адрес.
Использование ТСР-каналов
В настоящий момент ваш удаленный объект доступен через сетевой протокол HTTP. Как уже упоминалось выше, этот протокол вполне совместим с брандмауэром, но генерируемые при этом пакеты SOAP немного "раздуты" (по причине представления данных в формате XML). Чтобы уменьшить сетевой трафик, можно изменить компоновочные блоки клиента и сервера так, чтобы в них использовался TCP-канал и, следовательно, тип BinaryFormatter. Вот подходящая модификация компоновочного блока сервера.
Замечание. Для файлов с определениями объектов, доступных по TCP-каналам о заданным URI, чаще всего (но не обязательно) используется расширение *.rem (от remote – удаленный).
// Корректировки для сервера.
using System.Runtime.Remoting.Channels.Tcp;
…
static void Main(string[] args) {
…
// Создание нового TcpChannel
TcpChannel с = new TcpChannel(32469);
ChannelServises.RegisterChannel(c);
// Регистрация WKO-объекта в режиме синглета.
RemotingConfiguration.RegisterWellKnownServiceType(typeof(SimpleRemotingAsm.RemoteMessageObject), "RemoteMsgObj.rem", WellKnownObjectMode.SingleCall);
Console.ReadLine();
}
Здесь в слое удаленного взаимодействия .NET регистрируется тип System. Runtime.Remoting.Channels.Tcp.TcpChannel. Кроме того, изменен URI-объект (теперь для него задано более общее имя RemoteMsgObj.rem вместо *.soap, что явно указывало на использование SOAP). Модификация приложения клиента так же проста.
// Корректировки для клиента.
using System.Runtime.Remoting.Channels.Тcр;
…
static void Main(string[] args) {
…
// Создание нового TcpChannel
TcpChannel с = new TcpChannel();
ChannelServices.RegisterChannel(c);
// Получение агента для удаленного объекта.
object remoteObj = Activator.GetObject(typeof(SimpleRemotingAsm.RemoteMessageObject), "tcp://localhost:32469/RemoteMsgObj.rem");
// Использование объекта.
RemoteMessageObject simple = (RemoteMessageObject)remoteObj;
simple.DisplayMessage("Привет от клиента!");
Console.WriteLine("Сервер говорит: {0}", simple.ReturnMessage());
Console.ReadLine();
}
Единственным заслуживающим внимания моментом здесь является то, что URL активизации клиента теперь должен содержать признак канала tcp://, а не http://. Во всем остальном программная логика здесь оказывается идентичной программной логике HttpChannel,
Исходный код. Проекты TCPSimpleRemoteObjectServer и TCPSimpleRemoteObjectClient размещены в подкаталоге, соответствующем главе 18 (оба эти проекта используют созданный выше компоновочный блок SimpleRemotingAsm.dll).
Несколько слов о IpcChannel
Перед тем как перейти к обсуждению файлов конфигурации удаленного взаимодействия, напомним, что .NET 2.0 предлагает тип IpcChannel, обеспечивающий самый быстрый из возможных способов взаимодействия приложений на одной машине. Задачей данной главы является изучение возможностей построения распределенных приложений, выполняемых не на одном, а на множестве компьютеров. Поэтому по поводу использования IpcChannel обратитесь к документации .NET Framework 2.0 SDK (как и следует ожидать, соответствующий программный код будет почти идентичен программному коду, необходимому для работы с HttpChannel и TcpChannel).
Файлы конфигурации удаленного взаимодействия
Итак, вы успешно построили распределённое приложение, используя слой удаленного взаимодействия .NET. В связи c данными примерами следует обратить внимание на то что полученные приложения клиента и сервера содержат большой объем "жестко" кодируемой программной логики. Например, сервер указывает фиксированный идентификатор порта, фиксированный режим активизации и фиксированный тип канала. Клиент, с другой стороны, "жестко" кодирует имя удаленного объекта, с которым пытается взаимодействовать.
