1.4.2. Конфигурирование удаленных объектов
Процесс конфигурирования объектов типа 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.