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

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

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

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

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

Еще одной проблемой выбора, возникающей перед вами, как программистом, является принятие решения о том, когда следует активизировать 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-типы могут создаваться только с помощью конструктора, заданного по умолчанию. Это разумно, поскольку конструктор удаленного типа используется только тогда, когда клиент выполняет вызов члена. Так что среда выполнения не имеет никакого иного варианта выбора, кроме вызова конструктора, заданного типом по умолчанию.

Замечание. Всегда помните о том, что любой WKD-тип должен иметь конструктор, заданный по умолчанию!

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

Наконец, еще одна проблема выбора для MBR-типов в проекте .NET связана с тем, как сервер должен обрабатывать множественные обращения к WKO-типу. С САО-типами эта проблема не возникает, поскольку для них всегда есть однозначное соответствие между клиентом и удаленным САО-типом (эти типы являются объектами, кумулятивно изменяющими параметры своего состояния в процессе выполнения вызовов клиентов).

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

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

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

public enum WellKnownObjectMode {

 SingleCall,

 Singleton

}

Вы имели возможность убедиться в том, что для конфигурации MBV-объек-тов долгих размышлений не потребуется: нужно просто применить атрибут [Serializable], чтобы позволить отправку копий соответствующего типа в домен приложения клиента. С этого момента все взаимодействие с MBV-типом происходит в локальном окружении клиента. Когда клиент завершит использование соответствующего MBV-типа, этот тип становится объектом внимания сборщика мусора, и никаких проблем не возникает.

Но для MBR-типов имеется целый ряд вариантов конфигурации. Вы видели, что MBR-тип допускает варианты конфигурации в отношении его времени активизации, состояния и управления циклом существования. Чтобы представить весь набор имеющихся возможностей, в табл. 18.3 показано, как WKO и САО-объекты соотносятся с вариантами поведения, которые только что были нами рассмотрены.

Таблица 18.3. Опции конфигурации для MBR-типов 

Характеристика MBR-объекта Поведение WKO-типа Поведение САО-типа Опции создания экземпляра WKO-типы могут активизироваться только c помощью конструктора, заданного по умолчанию, который запускается при первом вызове метода клиентом CAO-типы могут активизироваться с помощью любого конструктора типа. Удаленный объект создается тогда, когда вызывающая сторона использует семантику конструктора (или тип Activate) Управление состоянием WKO-типы можно сконфигурировать, как синглет или объект одиночного вызова. Синглет может обслуживать множество клиентов и является объектом, кумулятивно изменяющим параметры своего состояния в процессе выполнения вызовов клиентов. Объект одиночного вызова существует только в процессе данного вызова клиента и является объектом, не меняющим своего состояния в процессе выполнения Цикл существования САО-типа контролируется вызывающей стороной, поэтому САО-типы являются объектами, кумулятивно изменяющими параметры своего состояния в процессе выполнения вызовов клиентов Управление циклом существования Для WKO-типов, являющихся синглетами, используется схема лизингового управления (которая будет описана в этой главе позже). WKO-типы, являющиеся объектами одиночного вызова, оказываются объектами внимания для сборщика мусора сразу же по завершении вызова метода Для CAO-типов используется схема лизингового управления (которая будет описана в этой главе позже)