Важно понимать, что вне зависимости от типа канала, который вы выберете для использования, и HttpChannel, и TcpChannel, и IpcChannel реализуют интерфейсы IChannel, IChannelSender и IChannelReceiver. Интерфейс IChannel (как вы вскоре убедитесь) определяет небольшой набор членов, обеспечивающих общую функциональность всех типов каналов. Роль IChannelSender заключается в определении для каналов общего множества членов, позволяющих отправлять информацию данному получателю. С другой стороны, IChannelReceiver определяет множество членов, позволяющих каналу получать информацию данного отправителя.
Чтобы позволить приложениям клиента и сервера зарегистрировать выбранный ими канал, вы должны использовать метод ChannelServices.RegisterChannel(), который получит тип, реализующий IChannel. Вот фрагмент программного кода, который показывает, как домен серверного приложения может зарегистрировать HTTP-канал, использующий порт 32469 (аналогичные возможности клиента будут продемонстрированы чуть позже).
// Создание и регистрация HttpChannel-сервера с портом 32469.
HttpChannel c = new HttpChannel(32469);
ChannelServices.RegisterChannel(с);
Снова о роли форматтера .NET
Заключительным элементом головоломки удаленного взаимодействия .NET является форматтер. Типы TcpChannel и HttpChannel используют свои внутренние форматтеры, задачей которых является перевод объекта сообщения в термины соответствующего протокола. Как уже говорилось, тип TcpChannel использует тип BinaryFormatter, в то время как тип HttpChannel использует функциональные возможности типа SoapFormatter. Опираясь на знания, полученные в предыдущей главе, вы должны понимать, как соответствующий канал форматирует поступающие сообщения.
После создания форматированного сообщения оно передается в канал, по которому в конце концов достигает целевого домена приложения. Там это сообщение преобразуется из специфических терминов протокола обратно в термины .NET, после чего элемент, который называется диспетчер, вызывает нужный метод удаленного объекта.
Общая картина
Если у вас от чтения предыдущих разделов уже голова идет кругом, не паникуйте! Прозрачный агент, реальный агент, объект сообщения и диспетчер вы можете, как правило, просто игнорировать, поскольку чаще всего вам вполне подойдут параметры удаленного взаимодействия, предлагаемые по умолчанию. Чтобы закрепить в памяти соответствующую последовательность событий, рассмотрите рис. 18.1, на котором показана схема процесса коммуникации двух объектов из разных доменов приложений.
Рис. 18.1. Архитектура удаленного взаимодействия .NET, предлагаемая по умолчанию
Несколько слов о расширении стандартных возможностей
Ключевой особенностью слоя удаленного взаимодействия .NET является то, что большинство предлагаемых по умолчанию слоев удаленного взаимодействия может быть расширено или полностью заменено разработчиком приложения. Так, если вы хотите (или, возможно, вам нужно) построить диспетчер пользовательских сообщений, пользовательский форматтер или реальный агент, вы имеете для этого все возможности. Вы также можете добавить дополнительные слои, включив в цепочку обработки пользовательские типы (например, пользовательский приемник, используемый для предварительной или последующей обработки сообщений). Вам лично, возможно, никогда и не придется модифицировать базовый слой удаленного взаимодействия .NET, но факт в том, что платформа .NET предлагает пространства имен, позволяющие решить такую задачу.
Замечание. В этой главе тема расширения базового слоя удаленного взаимодействия .NET не обсуждается. Чтобы узнать, как это сделать, обратитесь к книге Ingo Rammer, Advanced .NET Remoting (Apress, 2002).
Термины удаленного взаимодействия .NET
Подобно любой новой парадигме, удаленное взаимодействие .NET предлагает свой собственный набор трехбуквенных акронимов. Поэтому, перед тем как рассмотреть первый пример программного кода, нам с вами придется определить несколько терминов, обычно используемых при описании приложения удаленного взаимодействия .NET. Как вы можете догадаться сами, соответствующая терминология используется для описания ответов на ряд общих вопросов, возникающих при построении распределенного приложения. Как передать тип через границы домена приложения? Когда именно будет активизирован удаленный тип? Как управлять циклом существования удаленного объекта (и т.д.)? Когда вы поймете соответствующую терминологию, вопросы построения распределенных приложений .NET уже не будут вам казаться столь запутанными.
Варианты маршалинга для объектов: MBR и MBV
В рамках платформы .NET вы имеете на выбор два варианта того, как предоставить удаленный объект клиенту. Упрощенно говоря, маршалинг описывает правила передачи удаленного объекта из одного домена приложения в другой. При разработке объекта, предусматривающего удаленное использование, вы можете выбрать либо семантику MBR (marshal-by-reference – маршалинг по ссылке), либо семантику MBV (marshal-by-value – маршалинг по значению). Их различие заключается в следующем.
• MBR-объекты. Вызывающая сторона получает агента для осуществления доступа к удаленному объекту.
• MBV-объекты. Вызывающая сторона получает полную копию объекта для использования в своем домене приложения.
При использовании типа, относящегося к MBR-объектам, среда CLR обеспечит создание в домене приложения клиента прозрачного и реального агентов, в то время как сам MBR-объект будет оставаться в домене приложения сервера. При вызове методов удаленного типа клиентом система удаленного взаимодействия .NET (схема которой описана выше) активизируется, чтобы выполнить задачи упаковки, отправки и получения информации при обмене данными через границы доменов приложений. Для этого MBR-объекты имеют ряд свойств, "простирающихся" за рамки их физического расположения. Вы увидите, что MBR-объекты имеют различные опции конфигурации, относящиеся к их активизации и управлению циклом существования. В противоположность этому, MBV-объекты представляют собой локальные копии удалённых объектов (использующие протокол сериализации .NET, который был рассмотрен в главе 17). MBV-объекты имеют намного меньше опций конфигурации, поскольку их цикл существования контролируется непосредственно клиентом. Подобно любому другому объекту .NET, после того как клиент освободит все ссылки на MBV-тип, этот тип становится потенциальным объектом внимания для сборщика мусора. Поскольку MBV-типы являются локальными копиями удаленных объектов, процесс вызова клиентом членов соответствующего типа, вообще говоря, не предполагает никакой сетевой активности.
Следует понимать, что вполне естественным для сервера является поддержка доступа к множеству MBR- и MBV-типов. Вы можете также догадаться, что MBR-типы обычно поддерживают методы, возвращающие различные MBV-типы, что, в общем-то, напоминает автоматизированное предприятие, где один объект создает и выпускает другие связанные объекты. Здесь возникает следующий вопрос: как сконфигурировать пользовательский тип класса для использования в виде MBR-или MBV-объекта?
Конфигурация MBV-объекта
Процесс конфигураций объекта для использования в виде MBV-типа абсолютно аналогичен процессу конфигурации объекта для сериализации. Просто объявите соответствующий тип с атрибутом [Serializable].
[Serializable]
public class SportsCar {…}
Конфигурация MBR-объекта
MBR-объекты не маркируются специальным атрибутом .NET, а получаются (явно или неявно) из базового класса System.MarshalByRefObject.
public class SportsCarFactory: MarshalByRefObject {…}
Формально тип MarshalByRefObject определяется следующим образом.
public abstract class MarshalByRefObject: object {
public virtual ObjRef CreateObjRef(Type requestedType);
public virtual bool Equals(object obj);
public virtual int GetHashCode();
public virtual object GetLifetimeService();
public Type GetType();
public virtual object InitializeLifetimeService();
public virtual string ToString();
}
Функциональные возможности, наследуемые от System.Object, вполне понятны, а роль остальных членов описана в табл. 18.2.
Таблица 18.2. Основные члены System.MarshalByRefObject
Член Описание CreateObjRef() Создает объект, содержащий всю информацию, необходимую для генерирования агента, который будет использоваться для взаимодействия с удаленным объектом GetLifetimeServices() Возвращает текущий сервис-объект, контролирующий политику цикла существования для данного экземпляра InitializeLifetimeServices() Генерирует сервис-объект для контроля политики цикла существования данного экземпляра
Можно сказать, что суть типа MarshalByRefObject заключается в определении членов, которые затем могут переопределяться для того, чтобы программно управлять циклом существования MBR-объекта (подробнее об управлении циклом существования объектов будет говориться в этой главе позже).
