Эндрю Троелсен - ЯЗЫК ПРОГРАММИРОВАНИЯ С# 2005 И ПЛАТФОРМА .NET 2.0. 3-е издание

Наконец, еще одна проблема выбора для 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-типов

Хватит акронимов! К этому моменту вы почти готовы к построению своего первого .NET-приложения, использующего удаленное взаимодействие. Но перед тем, как это сделать, мы должны обсудить одну деталь: процедуру инсталляции. При создании приложения удаленного взаимодействия .NET вы, скорее всего, будете иметь три (да, именно три, а не два) разных компоновочных блока .NET, составляющих ваше приложение. Я уверен, что первые два компоновочных блока вы смо-жете указать сами.

• Клиент . Этот компоновочный блок представляет сущность (например, приложение Windows Forms или консольное приложение), заинтересованную в получении доступа к удаленному объекту.

• Сервер. Этот компоновочный: блок представляет сущность, получающую канальные запросы от удаленного клиента и обслуживающую удаленные объекты.

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

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

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

• Использовать приложение командной строки soapsuds.exe. С помощью этого инструмента можно сгенерировать компоновочный блок, содержащий только метаданные удаленных типов.