Конфигурирование удаленных объектов

Процесс конфигурирования объектов типа MBV идентичен процессу конфигурирования объекта для сериализации. Просто объявите тип с атрибутом [Serializable]: [Serializable]

public class SportsCar {...}

Объекты MBR не помечаются атрибутом. NET, а вместо этого наследуются (напрямую или опосредованно) от базового класса System.MarshalByRefObject:

public class SportsCarFactory: MarshalByRefObject

{...}

Формально тип MarshalByRefObject определен так:

public abstract class MarshalByRefObject: object

{

public virtual ObjRef CreateObjRef(Type requestedType);

public virtual bool Equals(object obj);

public virtual int GetHashCode();

public virtual object GetLifetimeService();

public Type GetType();

public virtual object InitializeLifetimeService();

public virtual string ToString();

}

Помимо ожидаемой функциональности, предоставленной типом System.Object, в табл. 1.2 описаны роли остальных его членов.

Таблица 1.2. Ключевые члены System.MarshalByRefObject

Суть MarshalByRefObject состоит в определении членов, которые могут быть переопределены для того, чтобы программно управлять циклом существования MBR-объекта.

На заметку! Конфигурация типа как MBV- или MBR-объекта, еще не означает, что он будет пригоден для использования только в распределенном приложении, а означает только то, что этот объект можно использовать в таком приложении. Например, тип System.Windows.Forms.Form также является потомком MarshalByRefObject. Поэтому при удаленном доступе он реализуется как MBR-тип, а в других случаях он будет обычным локальным объектом в домене приложения клиента.

На заметку! Если тип не предполагает сериализацию и в его цепочке наследования нет MarshalByRefObject, то такой тип является контекстно-связанным. То есть, такой тип может быть активизирован и использован только в исходном домене приложения (т.е. тип привязан к контексту).

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

1.4.3. Активизация удаленных объектов MBR- типа

Еще один выбор, с которым сталкивается программист, связан с тем, когда следует активизировать объект MBR, и когда он должен стать кандидатом на сборку мусора на сервере. Это может показаться странным, поскольку вполне естественно предположить, что MBR- объекты создаются, когда клиент запрашивает их, и исчезают, когда клиент завершает работу с ними. Но верно и то, что клиент полностью отвечает за настройку слоя удаленного взаимодействия для того, чтобы указать, как он желает работать с удаленным объектом и должен ли (или нет) серверный домен приложений создавать удаленный объект именно в тот момент, когда код клиента запрашивает его. Конечно, именно клиент предоставляет слою удаленного взаимодействия информацию о своем желании взаимодействовать с удаленным объектом, но в ответ на запрос клиента серверное приложение имеет возможность создать объект соответствующего типа не сразу.

Причина этого на первый взгляд странного поведения состоит в оптимизации. В частности, каждый MBR-тип можно настроить с использованием одного из двух подходов:

• как хорошо известный (или общеизвестный) объект (well-known object — WKO);
• как объект, активизируемый клиентом (client-activated object — CAO).

На заметку! Потенциальной причиной путаницы может быть тот факт, что в литературе, посвященной.NET, вместо аббревиатуры WKO также используют
SAO (server-activated object – объект активизируемый сервером). Аббревиатуру SAO можно встретить в различных статьях и книгах на тему. NET. Однако ради сохранения последовательности, будет применять понятие WKO.

Объекты WKO — это MBR -типы, циклом существования которых управляет непосредственно домен серверного приложения. Приложение клиентской стороны активизирует удаленный тип, используя понятное, хорошо известное строковое имя. Домен серверного приложения размещает в памяти объекты WKO -типа тогда, когда клиент осуществляет первый вызов метода данного объекта (через прозрачный прокси), а не когда программный код клиента использует ключевое слово new или когда вызов происходит через статический метод Activator.GetObject (). Например:

// Получение прокси для удаленного объекта.

//Эта строка не приводит к немедленному созданию экземпляра WKO- типа!

object remoteObj = Activator.GetObject(/* параметры... */

// Вызов метода удаленного объекта WKO-типа. Это приводит к созданию объект

// WKО-объекта и вызову метода ReturnMessage().

RemoteMessageObject simple = (RemoteMessageObject)remoteObj;

Console.WriteLine(" Server says: {0}", simple.ReturnMessage());

Как объяснить такое поведение? Дело в том, что при таком подходе простая команда создать объект не ведет к немедленному пику сетевого обмена данными. То есть позволяет экономить сетевой трафик, исключая обмен, связанный исключительно с созданием нового объекта. Еще одно интересное следствие заключается в том, что объекты WKO -типов могут создаваться только конструкторами по умолчанию. Это имеет смысл, учитывая то, что конструктор удаленного типа вызывается только тогда, когда клиент осуществляет начальный вызов члена. Таким образом, исполняющая среда не имеет другого выбора, как вызвать конструктор по умолчанию.

На заметку! Необходимопомнить, что все типы WKO должны поддерживать конструктор по умолчанию!

Если нужно разрешить клиенту создавать MBR -объекты с помощью пользовательского (специального) конструктора, то сервер должен сконфигурировать соответствующий объект как CAO -объект. Объекты CAO — это объекты, жизненный цикл которых управляется доменом клиентского приложения. При обращении к CAO -объекту обмен данными с сервером происходит при использовании клиентом ключевого слова new (с любым конструктором типа) или с помощью объекта типа Activator.

1.5.4. Конфигурирование объектов WKO -типа

Рассмотрим еще одну задачу, которую требуется решить, при выборе MBR -типов в проекте. NET. Она заключается в необходимости определения способа, каким сервер должен обрабатывать множественные запросы к типу WKO. Типов CAO это не касается, потому что там всегда существует однозначное соответствие (отношение “один к одному”) между клиентом и удаленным CAO- типом (поскольку они являются объектами с состоянием).

Первый вариант состоит в конфигурировании типа WKO для работы в режиме одиночного экземпляра (синглета - singleton). В этом случае CLR создает единственный экземпляр удаленного типа, который принимает запросы от любого числа клиентов. Этот вариант оказывается наиболее естественным тогда, когда нужно поддерживать состояние типа, одинаковое для всех абонентов. Учитывая то обстоятельство, что множество клиентов могут вызывать один и тот же метод в одно и то же время, среда CLR помещает каждый вызов клиента в новый поток выполнения. Однако, в этом случае на вас возлагается ответственность за обеспечение безопасности к потокам объектов.

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

Задача определения конфигурации состояния объекта WKO -типа возлагается на сервер. Программно эти опции настройки выражаются перечислением System.Runtime.Remoting.WellKnownObjectMode:

public enum WellKnownObjectMode

{

SingleCall,

Singleton

}