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

Если у вас от чтения предыдущих разделов уже голова идет кругом, не паникуйте! Прозрачный агент, реальный агент, объект сообщения и диспетчер вы можете, как правило, просто игнорировать, поскольку чаще всего вам вполне подойдут параметры удаленного взаимодействия, предлагаемые по умолчанию. Чтобы закрепить в памяти соответствующую последовательность событий, рассмотрите рис. 18.1, на котором показана схема процесса коммуникации двух объектов из разных доменов приложений.

Рис. 18.1. Архитектура удаленного взаимодействия .NET, предлагаемая по умолчанию

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

Замечание.В этой главе тема расширения базового слоя удаленного взаимодействия .NET не обсуждается. Чтобы узнать, как это сделать, обратитесь к книге Ingo Rammer, Advanced .NET Remoting (Apress, 2002).

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

В рамках платформы .NET вы имеете на выбор два варианта того, как предоставить удаленный объект клиенту. Упрощенно говоря, маршалинг описывает правила передачи удаленного объекта из одного домена приложения в другой. При разработке объекта, предусматривающего удаленное использование, вы можете выбрать либо семантику MBR (marshal-by-reference – маршалинг по ссылке), либо семантику MBV (marshal-by-value – маршалинг по значению). Их различие заключается в следующем.

• MBR-объекты. Вызывающая сторона получает агента для осуществления доступа к удаленному объекту.

• MBV-объекты. Вызывающая сторона получает полную копию объекта для использования в своем домене приложения.

При использовании типа, относящегося к MBR-объектам, среда CLR обеспечит создание в домене приложения клиента прозрачного и реального агентов, в то время как сам MBR-объект будет оставаться в домене приложения сервера. При вызове методов удаленного типа клиентом система удаленного взаимодействия .NET (схема которой описана выше) активизируется, чтобы выполнить задачи упаковки, отправки и получения информации при обмене данными через границы доменов приложений. Для этого MBR-объекты имеют ряд свойств, "простирающихся" за рамки их физического расположения. Вы увидите, что MBR-объекты имеют различные опции конфигурации, относящиеся к их активизации и управлению циклом существования. В противоположность этому, MBV-объекты представляют собой локальные копии удалённых объектов (использующие протокол сериализации .NET, который был рассмотрен в главе 17). MBV-объекты имеют намного меньше опций конфигурации, поскольку их цикл существования контролируется непосредственно клиентом. Подобно любому другому объекту .NET, после того как клиент освободит все ссылки на MBV-тип, этот тип становится потенциальным объектом внимания для сборщика мусора. Поскольку MBV-типы являются локальными копиями удаленных объектов, процесс вызова клиентом членов соответствующего типа, вообще говоря, не предполагает никакой сетевой активности.