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

Замечание. Как следствие предыдущего замечания обратим внимание на то, что если тип .NET не предполагает сериализацию и в его цепочке наследования нет MarshalByRefObject, то такой тип может активизироваться и использоваться только в его исходном домене приложения, т.е, такой тип является контекстно-связанным (см. главу 13).

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

Варианты активизации для MBR-типа: WKO и CAO

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

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

• как общеизвестный объект (Well-Known Object – WKO);

• как объект, активируемый клиентом (Client Activated Object – CAO).

Замечание. Потенциальным источником недоразумений здесь является то, что в литературе, посвященной .NET, вместо акронима WKO также используют SAO (Server Activated Object – объект, активизируемый сервером). Акроним SAO встречается в целом ряде статей и книг, связанных с .NET. В этой главе, в соответствии с современной терминологией, будет использоваться аббревиатура WKO.

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

// Получение агента для удаленного объекта.
// Эта строка не приводит к немедленному создании WKO-типа!
object remoteObj = Activator.GetObject(/* параметры… */);
// Вызов метода удаленного WKO-типа. Это приводит к созданию
// WKO-объекта и вызову метода ReturnMessage().
RemoteMessageObject simple = (RemoteMessageObject)remoteObj;
Console. WriteLine("Сервер отвечает: {0}", simple.ReturnMуssage());

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