1. Теоретическая часть

1.1. Принципы (Каркас) организации удаленного взаимодействия .Net Remoting

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

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

• прокси (представители или заместители);

• сообщения;

• каналы;

• форматировщики.

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

1.2. Прокси и сообщения

Клиентские и серверные объекты не взаимодействуют между собой напрямую, а используют так называемого посредника, именуемого прокси. Роль объектов прокси заключается в том, чтобы заставить клиента поверить в то, что он действительно взаимодействует непосредственно с удаленным объектом, который расположен в том же домене приложений (адресном пространстве). Чтобы создать такую иллюзию, прокси имеет такой же интерфейс (т.е. методы и свойства), как и объект, который он замещает (представляет). С точки зрения клиента, конкретный прокси объекта и является самим удаленным объектом. “За кулисами”, однако, прокси передает все вызовы удаленному объекту.

Формально говоря прокси, вызываемый непосредственно клиентом, называется прозрачным прокси. Объект прокси автоматически генерируется CLR и отвечает за правильное предоставление клиенту набора свойств и методов удаленного объекта, а также количество и типы аргументов в каждом удаленном методе. С учетом этого, прозрачный прокси можно рассматривать как фиксированный промежуточный слой, который не может быть модифицирован или расширен программно.

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

System.Runtime.Remoting.Messaging.IMessage:

public interface IMessage

{

IDictionary Properties { get; }

}

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

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

public abstract class RealProxy : object

{

public virtual ObjRef CreateObjRef(Type requestedType);

public 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(RealProxy 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(). Дело в том, что сгенерированный CLR прозрачный прокси передает объект форматированного сообщения в тип реального прокси (RealProxy) именно через метод Invoke().