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

}

1.5.5. Особенности объектов mbr-типа

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

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

1.5. Инсталляция приложения, использующего удаленное взаимодействие

Теперь мы почти готовы к построению первого приложения .NET Remoting. Однако перед этим понадобится рассмотреть последнюю деталь – процедуру инсталляции. По сути дела, при создании приложения удаленного взаимодействия программист имеет дело с тремя отдельными сборками, которые составляют приложение. С двумя из них мы уже знакомы:

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

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

Что же собой представляет третья сборка? Во многих случаях серверное приложение обычно содержит в себе третью сборку, которая определяет и реализует удаленные объекты. Для удобства назовем ее общей сборкой (general assembly) или общим компоновочным блоком. Это отделение сборки, содержащей удаленные объекты, от сборки хоста сервера довольно важно, поскольку обычно клиентская и серверная сборки устанавливают ссылки на общую сборку, чтобы получить метаданные типов, допускающих удаленный доступ.

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

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

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

• Вручную построить сборку, содержащую только метаданные удаленных типов.

Чтобы не усложнять, мы будем строить и развертывать общие сборки, содержащие необходимые метаданные вместе с реализациями на языке MCIL.