Читать «ЯЗЫК ПРОГРАММИРОВАНИЯ С# 2005 И ПЛАТФОРМА .NET 2.0. 3-е издание» онлайн - страница 430

Эндрю Троелсен

// Корректировки для клиента.

…

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 данными примерами следует обратить внимание на то что полученные приложения клиента и сервера содержат большой объем "жестко" кодируемой программной логики. Например, сервер указывает фиксированный идентификатор порта, фиксированный режим активизации и фиксированный тип канала. Клиент, с другой стороны, "жестко" кодирует имя удаленного объекта, с которым пытается взаимодействовать.

Согласитесь, слишком наивно предполагать, что исходные параметры проекта смогут оставаться неизменными при любой инсталляции приложения. В идеале такие параметры, как номер порта, режим активизации и другие подобные элементы, должны позволять динамическое изменение без перекомпиляции и переустановки приложений клиента и сервера. В соответствии со схемой удаленного взаимодействия .NET все упомянутые здесь проблемы могут быть решены с помощью файла конфигурации удаленного взаимодействия;.

Вспомните из главы 11 о том, что файл *.config можно использовать для "подсказок" среде CLR в отношений места нахождения внешних компоновочных блоков, необходимых для работы приложения. Эти же файлы *.config могут использоваться и для информирования CLR о целом ряде параметров удаленного взаимодействия, как на стороне клиента, так и на стороне сервера.