Каналы связи

Как только прокси проверил и сформатировал аргументы на клиентской стороне в объект сообщения, то этот IMessage -совместимый тип передается от реального прокси объекту канала. Каналы — это сущности, отвечающие за транспортировку сообщения удаленному объекту и, если необходимо, гарантирующие, что любое возвращаемое удаленным методом значение будет передано обратно клиенту. Библиотеки базовых классов. NET предлагают три готовые реализации каналов:

• канал TCP;
• канал HTTP;
• канал IPC.

Канал TCP представлен классом TcpChannel и служит для передачи сообщений с использованием сетевого протокола TCP/IP. TcpChannel полезен тем, что сформатированные пакеты относительно легковесны, учитывая, что сообщения преобразуются в компактный двоичный формат с применением связанного с ним бинарного форматера - BinaryFormatter. Использование TcpChannel имеет тенденцию ускорять удаленный доступ. Отрицательной стороной каналов TCP является то, что они блокируются брандмауэрами и могут потребовать обращения к системному администратору, чтобы он специально разрешил передачу сообщений между машинами.

В отличие от этого, каналы HTTP, представленные типом HttpChannel, преобразуют объекты сообщений в формат SOAP, используя соответствующий форматировщик SOAP. SOAP опирается на использование XML, и потому имеет тенденцию создавать нагрузку, которая превышает нагрузку при использовании канала типа TcpChannel. Учитывая это, применение HttpChannel может несколько замедлить удаленный доступ. Однако положительная сторона заключается в том, что HTTP гораздо меньше страдает от преград брандмауэров, поскольку передает текстовые пакеты через порт 80.

И, наконец, в нашем распоряжении есть канал IPC, представленный типом IpcChannel. Этот тип определяет коммуникационный канал для удаленного взаимодействия с использованием системы IPC операционной системы Windows. Поскольку IpcChannel минует традиционные сетевые коммуникации для преодоления границ доменов приложений, то он намного быстрее, чем каналы HTTP и TCP. Однако, он может применяться только для взаимодействия между доменами приложений в пределах одного и того же физического компьютера. С учетом этого, вы никогда не сможете использовать IpcChannel для построения распределенных приложений, охватывающих несколько физических компьютеров. Тем не менее, IpcChannel может быть идеальным выбором, когда нужно, чтобы две локальные программы разделяли между собой информацию самым быстрым их возможных способов.

Независимо от того, какой тип канала выбран, необходимо знать, что типы HttpChannel, TcpChannel и IpcChannel реализуют интерфейсы IChannel, IChannelSender и IChannelReceiver. Интерфейс IChannel определяет небольшой набор членов, предоставляющих функциональность для всех типов каналов. Роль IChannelSender заключается в определении общего множества членов для каналов, способных передавать информацию определенному приемнику. С другой стороны, IChannelReceiver определяет множество членов, позволяющих каналу принимать информацию от заданного отправителя.

Чтобы позволить клиентскому и серверному приложениям регистрировать выбранный ими канал, применяется метод ChannelServices.RegisterChannel (), который принимает тип, реализующий IChannel. Показанный ниже фрагмент кода иллюстрирует то, как домен приложения серверной стороны может регистрировать канал HTTP на порте 32469:

// Создать и зарегистрировать HttpChannel серверной стороны на порте 32469.

HttpChannel c = new HttpChannel(32469);

ChannelServices.RegisterChannel(c);

Для того, транслировать объект сообщения в специфичный для протокола вид каналы типа TcpChannel и HttpChannel используют внутренний форматировщик.

При этом тип TcpChannel использует тип форматера BinaryFormatter, в то время как HttpChannel пользуется функциональностью, предоставленной типом SoapFormatter.

Как только сформатированное сообщение сгенерировано, оно передается в канал, через который, в конечном итоге, достигает целевого домена приложений, где это сообщение форматируется из специфичного для протокола вида обратно в вид, специфичный для.NET, и в этот момент объект (сущность) по имени диспетчер вызывает корректный метод удаленного объекта.

На рис.1, представлен базовый процесс взаимодействия двух объектов из двух разных доменов приложений.

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