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

Пространства имен удаленного взаимодействия .NET

Таблица 18.1. Пространства имен .NET для поддержки возможностей удаленного взаимодействия

Каркас удаленного взаимодействия .NET

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

В сущности, слой удаленного взаимодействия .NET обеспечивает аккуратную совместную работу следующих четырех ключевых элементов:

• агенты;

• сообщения;

• каналы;

• форматтеры.

Давайте рассмотрим каждый из указанных элементов по очереди и выясним, как их комбинация позволяет осуществлять удаленные вызовы методов.

Агенты и сообщения

Клиенты и объекты сервера взаимодействуют не напрямую, а через посредника, обычно называемого агентом (или proxy-модулем). Роль агента .NET заключается в создании для клиента иллюзии того, что он взаимодействует с запрошенным удаленным объектом в одном домене приложения. Чтобы создать такую иллюзию, агент предлагает интерфейс (члены, свойства, поля и т.д.), идентичный интерфейсу удаленного типа. С точки зрения клиента данный агент и является удаленным объектом. Однако "за кулисами" агент переправляет вызовы удаленному объекту.

Формально такой агент, вызываемый клиентом непосредственно, называется прозрачным агентом (transparent proxy). Этот объект, генерируемый средой CLR автоматически, несет ответственность за проверку того, что при вызове удаленного метода клиент получит нужное число параметров (и они будут нужного типа). Поэтому прозрачный агент можно интерпретировать, как фиксированный слой взаимодействия, который нельзя программно изменить или расширить.

public interface IMessage {
 IDictionary Properties { get; }
}

Как видите, интерфейс IMessage определяет единственное свойство (с именем Properties), которое обеспечивает доступ к коллекции, используемой для хранения предоставленных клиентом аргументов. После наполнения объекта сообщения содержимым средой CLR, он будет передан родственному типу, называемому реальным агентом (real proxy).

Реальный, агент – это сущность, которая фактически посылает объект сообщения в канал (понятие канала будет обсуждаться ниже). Реальный агент, который (в отличие от прозрачного агента) может быть расширен программистом, представляется базовым типом класса с именем RealProxy (что и следовало ожидать). Снова следует подчеркнуть, что среда CLR генерирует клиентскую реализацию реального агента для использования по умолчанию, которая вполне подойдет вам если не во всех, то в большинстве случаев. Но чтобы иметь представление о функциональных возможностях, предлагаемых абстрактным базовым классом RealProxy, изучите формальное определение этого типа.