ЯЗЫК ПРОГРАММИРОВАНИЯ С# 2005 И ПЛАТФОРМА .NET 2.0. 3-е издание - Эндрю Троелсен
Шрифт:
Интервал:
Закладка:
Файлы конфигурации удаленного взаимодействия
Итак, вы успешно построили распределённое приложение, используя слой удаленного взаимодействия .NET. В связи c данными примерами следует обратить внимание на то что полученные приложения клиента и сервера содержат большой объем "жестко" кодируемой программной логики. Например, сервер указывает фиксированный идентификатор порта, фиксированный режим активизации и фиксированный тип канала. Клиент, с другой стороны, "жестко" кодирует имя удаленного объекта, с которым пытается взаимодействовать.
Согласитесь, слишком наивно предполагать, что исходные параметры проекта смогут оставаться неизменными при любой инсталляции приложения. В идеале такие параметры, как номер порта, режим активизации и другие подобные элементы, должны позволять динамическое изменение без перекомпиляции и переустановки приложений клиента и сервера. В соответствии со схемой удаленного взаимодействия .NET все упомянутые здесь проблемы могут быть решены с помощью файла конфигурации удаленного взаимодействия;.
Вспомните из главы 11 о том, что файл *.config можно использовать для "подсказок" среде CLR в отношений места нахождения внешних компоновочных блоков, необходимых для работы приложения. Эти же файлы *.config могут использоваться и для информирования CLR о целом ряде параметров удаленного взаимодействия, как на стороне клиента, так и на стороне сервера.
При создании файла *.config для указания различных параметров удаленного взаимодействия используют элемент ‹system.runtime.remoting›. Если у вашего приложения уже есть файл *.config, в котором указаны параметры размещения компоновочного блока, вы можете добавить элементы удаленного взаимодействия в этот же файл. Единый файл *.config, содержащий и настройки удаленного взаимодействия, и информацию привязки, должен выглядеть примерно так.
‹configuration›
‹sуstem.runtime.remoting›
‹!-- параметры удаленного взаимодействия клиента и сервера --›
‹/system.runtime.remoting›
‹runtime›
‹!-- информация привязки компоновочного блока --›
‹/runtime›
‹/configuration›
Если вам нечего указать в отношении привязки компоновочного блока, вы можете опустить соответствующий элемент ‹runtime› и использовать в файле *.config шаблон следующего вида.
‹configuration›
‹system.runtime.remoting›
‹!-- параметры удаленного взаимодействия клиента и сервера --›
‹/system.runtime.remoting›
‹/configuration›
Создание файлов *.config сервера
Файлы конфигурации на стороне сервера позволяют объявить объекты, которые будут доступны для удаленных вызовов, а также задать параметры канала и порта. Рассмотрим следующий вариант программной логики сервера.
// "Жестко" заданная программная логика сервера HTTP.
HttpChannel с = new HttpChannel(32469);
ChannelServices.RegisterChannel(с);
RemotingConfiguration.RegisterWellKnownServiceType(typeof(SimpleRemotingAsm.RemoteMessageObject), "RemoteMsgObj.soap", WellKnownObjectMode.Singleton);
Используя элементы ‹service›, ‹wellknown› и ‹channels›, эту программную логику можно заменить следующим файлом *.config.
‹configuration›
‹system.runtime.remoting›
‹application›
‹service›
‹wellknown mode="Singleton" type="SimpleRemotingAsm.RemoteMessageObject, SimpleRemotingAsm" objectUri="RemoteMsgObj.soap"/›
‹/service›
‹channels›
‹channelref="http"/›
‹/channels›
‹/application›
‹/system.runtime.remoting›
‹/configuration›
Обратите внимание на то, что значительная часть информации удаленного сервера указывается в контексте элемента ‹service› (не сервер!). Его дочерний элемент ‹wellknown› использует три атрибута (mode, type и objectUri) для регистрации WKO-объекта в слое удаленного взаимодействия .NET. Элемент ‹channels› может содержать любое число элементов ‹channel›, которые позволяют определить вид канала (в данном случае это HTTP), открываемого на сервере. Для ТСР-каналов вместо http нужно просто использовать лексему tcp.
Поскольку в этом случае вся необходимая информация содержится в файле SimpleRemoteObjectServer.exe.config, метод Main() серверной стороны значительно упрощается. В нем остается выполнить только вызов RemotingConfiguration.Configure() и указать имя соответствующего файла конфигурации.
static void Main(string[] args) {
// Регистрация WKO-объекта с помощью файла *.config.
RemotingConfiguration.Configure("SimpleRemoteObjectServer.exe.config");
Console.WriteLine("Старт сервера! Для остановки нажмите ‹Enter›");
Console.ReadLine();
}
Создание файлов *.config клиента
Клиенты тоже могут использовать файлы *.config удаленного взаимодействия. В отличие от файлов конфигурации сервера, в файлах конфигурации клиента для идентификации имени WKO-объекта используется элемент ‹client›. Вдобавок к возможности динамического изменения параметров удаленного взаимодействия без перекомпиляции базового программного кода, файлы *.config клиента позволяют создать тип агента непосредственно с помощью ключевого слова C# new, не используя метод Activator.GetObject(). Предположим, например, что у нас есть файл *.config клиента со следующим содержимым.
‹configuration›
‹system.runtime.remoting›
‹application›
‹client displayName = "SimpleRemoteObjectClient"›
‹wellknown type=" SimpleRemotingAsm.RemoteMessageObject, SimpleRemotingAsm" url="http://localhost:32469/RemoteMsgObj.soap"/›
‹/client›
‹channels›
‹channel ref="http"/›
‹/channels›
‹/application›
‹/system.runtime.remoting›
‹/configuration›
Тогда можно изменить метод Main() клиента так.
statiс void Main(string[] args) {
RemotingConfiguration.Configure("SimpleRemoteObjectClient.exe.config");
// При использовании файла *.config клиент может создать тип
// непосредственно с помощью ключевого слова 'new' .
RemoteMessageObject simple = new RemoteMessageObject();
simple.DisplayMessage("Привет от клиента!");
Console.WriteLine("Сервер говорит: {0}", simple.ReturnMessage());
Console.WriteLine("Старт клиента! Для остановки нажмите ‹Enter›");
Console.ReadLine();
}
При выполнении этого варианта приложения вывод оказывается аналогичным исходному. Если клиент пожелает использовать TCP-канал, то для свойств url элемента ‹wellknown› и ref элемента ‹сhannel› следует вместо http указывать tcp.
Исходный код. Проекты SimpleRemoteObjectServerWithConfig и SimpleRemoteObjectClientWithConfig размещены в подкаталоге, соответствующем главе 18 (оба эти проекта используют созданный выше компоновочный блок SimpleRemotingAsm.dll).
Работа с MBV-объектами
Наши первые приложения удаленного взаимодействия позволяли доступ клиентов к одному WKO-типу. Напомним, что WKO-типы (по определению) являются MBR-типами, поэтому доступ клиента к ним осуществляется через агента-посредника. В противоположность этому, MBV-типы являются локальными копиями серверного объекта, обычно возвращаемыми открытыми членами некоторого MBR-типа. Вы уже знаете, как настроить MBV-тип (следует обозначить соответствующий класс атрибутом [Serializable]), но MBV-тип в действии вы еще не видели (если не считать обмена строковыми данными между двумя сторонами). Для иллюстрации взаимодействия MBR- и MBV-типов мы рассмотрим новый пример, в котором используются следующие три компоновочных блока.
• Общий компоновочный блок CarGeneralAsm.dll
• Компоновочный блок клиента CarProviderClient.exe
• Компоновочный блок сервера CarProviderServer.exe
Как вы можете догадаться, программный код приложений клиента и сервера более или менее подобен программному коду соответствующих приложений предыдущего примера, особенно в том, как эти приложения используют файлы *.config, Тем не менее, давайте разберем соответствующий процесс построения каждого из указанных компоновочных блоков по очереди.
Создание общего компоновочного блока
В ходе нашего обсуждения процесса сериализации объектов в главе 17 мы создали тип JamesBondCar (в дополнение к связанным классам Radio и Car). Библиотека программного кода CarGeneralAsm.dll будет использовать эти типы, поэтому сначала выберите Projects→Add Existing Item из меню и добавьте в свой новый проект библиотеки классов соответствующие файлы *.cs (автоматически созданный файл Class1.cs можете удалить), Поскольку каждый из добавленных типов уже обозначен атрибутом [Serializable], они готовы для маршалинга по значению в отношении удаленного клиента.
Теперь нам нужен MBR-тип, который обеспечит доступ к типу JamesBondCar. Чтобы сделать ситуацию немного более интересной, ваш MBR-объект (CarProvider) будет поддерживать обобщенный список List‹› типов JamesBondCar. Тип CarProvider определит два члена, которые позволят вызывающей стороне получить заданный тип JamesBondCar, а также полный перечень List‹› соответствующих типов. Вот весь программный код для нового типа класса.
