Эндрю Троелсен - ЯЗЫК ПРОГРАММИРОВАНИЯ С# 2005 И ПЛАТФОРМА .NET 2.0. 3-е издание

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

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

• агенты;

• сообщения;

• каналы;

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

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

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

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

В предположении о том, что прозрачный агент может выполнять проверку входных аргументов, соответствующая информация упаковывается в другой генерируемый средой CLR тип, который называется объектом сообщения. По определению все объекты сообщений реализуют интерфейс System.Runtime.Remoting.Messaging.IMessage.

public interface IMessage{

IDictionary Properties { get; }

}

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

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

public abstract class RealProxy: object {

public virtual ObjRef CreateObjRef(Type requestedType);

publiс virtual bool Equals(object obj);

public virtual IntPtr GetCOMIUnknown(bool fIsMarshalled);

public virtual int GetHashCode();

public virtual void GetObjectData(SerializationInfo info, StreamingContext context);

public Type GetProxiedType();

public static object GetStubData(RеаlРrоxу rp);

public virtual object GetTransparentProxy();

public Type GetType();

public IConstructionReturnMessage InitializeServerObject(IConstructionCallMessage ctorMsg);

public virtual IMessage Invoke(IMessage msg);

public virtual void SetCOMIUnknown(IntPtr i);

public static void SetStubData(RealProxy rp, object stubData);

public virtual IntPtr SupportsInterface(ref Guid iid);

public virtual string ToString();

}

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

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

• TCP-канал;

• HTTP-канал;

• IPC-канал.

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

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

Наконец, в .NET 2.0 предлагается доступ к IPC-каналу, представленному типом IpcChannel, который определяет коммуникационный канал связи для удаленного взаимодействия с использованием IPC-архитектуры операционной системы Windows. Ввиду того, что IpcChannel при пересечении доменов приложений действует в обход традиционных систем сетевой коммуникации, IpcChannel оказывается намного быстрее, чем HTTP- и TCP-каналы, однако, может использоваться только для взаимодействия доменов приложения на одном и том же компьютере. Поэтому IpcChannel не может применяться для построения распределенных приложений, допускающих использование множества физических компьютеров. Но тип IpcChannel может оказаться идеальным вариантом тогда, когда вы хотите обеспечить наивысшую скорость обмена информацией между двумя локальными программами.