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
3. Откройте проект SimpleRemoteObjectClient и измените URL активизации в соответствии с именем удаленной машины, например:
// Получение агента для удаленного объекта.
object remoteObj = Activator.GetObject(typeof(SimpleRemotingAsm.RemoteMessageObject), "httр://ИмяУдаленнойМашины:32469/RemoteMsgObj.soap");
4. Запустите приложение SimpleRemoteObjectServer.exe на машине сервера.
5. Запустите приложение SimpleRemoteObjectClient.exe на машине клиента.
6. Откиньтесь на спинку кресла, расслабьтесь и улыбнитесь.
Замечание. Вместо понятного имени Машины URL активизации может указывать ее IP-адрес.
Использование ТСР-каналов