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

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

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

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

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

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

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

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