Текст книги "Основы проектирования корпоративных систем"

Итак, подводя итоги обсуждения технологии Windows Forms, технологии, поддерживающей эргономичный интерфейс корпоративных приложений, можно сделать следующие выводы. Во-первых, эта технология поддерживает высокую интерактивность, сценарную обработку данных, т. е. обработку данных на основе событий с высокой вариативностью – сценарии эти могут быть достаточно гибкими и адекватно реагирующими на самые разные действия пользователя. Windows Forms имеет огромное количество различных элементов управления, которые позволяют строить достаточно сложные и одновременно привычные пользователю и понятные ему элементы интерфейса – это DataGridView, командные кнопки, элементы меню и т. д. Пользователь в связи с этим получает возможность работать с корпоративными системами предсказуемым образом, повышает свою производительность и, следовательно, производительность труда в корпорации. Кроме того, осуществляется возможность доступа к гетерогенным источникам информации, что важно для корпоративных пользователей, в первую очередь посредством удаленного доступа. Пользователи получают возможность доступа к гетерогенным источникам данных, а также к аудио– и видеоинформации на основе XML-представления. И что очень важно, они имеют возможность агрегировать эту информацию, получать ее в едином интерфейсе, т. е. в гетерогенном отчете может быть представлен как текст, извлечение из отчета базы данных на основе запроса, так и определенная фото– и видеоинформация, которая извлечена из хранилищ данных. Технология Windows Forms позволяет без особых затрат производить обновление, коррекцию, усовершенствование отдельных компонентов программных систем и программных систем в целом. Пользователь получает возможность автоматического обновления, если осуществляется подписка на это обновление, поскольку Windows Forms является надстройкой на. NET и поддерживает все политики, протоколы шифрования данных, протоколы взаимодействия, в том числе по Интернету, которые реализованы для. NET Framework.

Итак, была рассмотрена технология Windows Forms, которая предназначена для создания эргономичных пользовательских интерфейсов корпоративных систем. При этом упоминалось, что эта технология поддерживает распределенные взаимодействия пользователей с гетерогенными источниками данных на основе таких элементов, как BindingSourceNavigator, и подобных средств организации доступа к гетерогенным источникам корпоративной информации. Теперь обсудим, каким образом осуществляется создание и поддержка распределенных приложений на платформе. NET, какие технологии используются. Прежде всего, речь пойдет о веб-сервисах и о технологии Remoting. Последняя разработана Microsoft, является достаточно жесткой, но тем не менее обеспечивает высокую безопасность и надежность приложений, что весьма важно для корпоративных систем. Обсудим ее в связи с другими технологиями сетевого взаимодействия компонентов распределенных приложений в корпоративной интернет-среде.

Во-первых, рассмотрим общий принцип функционирования распределенных приложений, а также их основные особенности, в которых явно выделяются роли клиента и сервера. Клиент и сервер – это не обязательно аппаратное обеспечение, это не обязательно один и тот же компьютер. Сервер может быть распределен по нескольким компьютерам – это, скорее, логические объекты. Мы рассмотрим различия и основные особенности веб-сервисов по отношению к технологии Remoting. Далее речь пойдет об основных понятиях, которыми следует оперировать при определении распределенных приложений. Рассмотрим низкоуровневые средства для работы с сетевыми приложениями и еще раз вернемся к технологии клиент-серверного взаимодействия для построения распределенных приложений корпоративного типа. Очень важна, особенно в связи с Remoting, процедура удаленного вызова процедур (RPC). Это важная технология, которая исторически достаточно рано возникла и, по сути, реализует базовую схему взаимодействия распределенных приложений, в том числе в интернет-среде. Мы обсудим, каким образом осуществляется компонентное проектирование и программирование в среде. NET, центральным понятием идеологии. NET является компонент, синонимом компонента выступает сборка.

По сути, проектирование корпоративных приложений как раз и ведется в терминах компонентов. При этом пользователь или заказчик получает строго определенное корпоративное приложение, собранное по заказу именно из тех компонентов, которые нужны для получения пользователем требуемой им функциональности. Таким образом пользователь может гибко определять необходимую функциональность и экономить средства именно за счет выбора строго определенных компонентов корпоративных приложений. Мы рассмотрим технологию Web Forms в связи с Windows Forms, которые мы рассмотрели раньше, т. е. те формы ввода данных и получения отчетной информации, которые предназначены специально для интернет-взаимодействия, и посмотрим сходства и различия с Windows Forms.

Итак, перейдем к процедуре построения корпоративных распределенных приложений на основе технологии Remoting и других технологий, связанных с веб-сервисами и клиент-серверной архитектурой. Общий принцип построения подобных систем заключается в следующем: объекты или модули распределенного приложения в случае компонентного подхода к проектированию (компоненты или сборки) располагаются физически на нескольких компьютерах и логически – в нескольких процессорах ОС. За счет специализации выделяется слой бизнес-логики, который реализуется на клиентской части и на сервере. За счет этого оптимизируется производительность клиента и сервера и осуществляется взаимодействие элементов распределенного приложения в наиболее выгодном режиме для пользователей, по сути, оптимизируется производительность программной системы, время реакции, производительность пользователей.

Какие основные понятия характеризует веб-сервисы и технологии Remoting? Технология Remoting является достаточно жесткой по сравнению с общей методологией веб-сервисов. Microsoft продвигает принцип предоставления ПО как сервиса, поэтому понятие веб-сервиса не только не чуждо методологии. NET, но и является одним из ее основных компонентов. Веб-сервисы представляют собой слабосвязанную модель взаимодействия объектов на основе общедоступных мировых стандартов. Это в первую очередь протоколы взаимодействия HTTP, SMTP. Веб-сервисы независимы от языка программирования, в отличие от Remoting. Еще очень важно, что веб-сервисы поддерживают модель работы с объектами без сохранения внутреннего состояния. То есть объекты, по сути, не имеют памяти о своей истории. Подход. NET Remoting является более строгим, более жестким, нацеленным исключительно на среду. NET, т. е. прежде всего на ОС Windows. Конечно, NET поддерживается и для узкого круга Unix-систем, в рамках проекта mono, но в целом ориентация преимущественно на. NET и Windows. Кроме того, модель нацелена на более эффективное и безопасное выполнение объектов в. NET, так как содержит встроенную систему безопасности, она поддерживает сборки и подписи, алгоритмы шифрования, поддерживаемые средой. NET. Таким образом, реализуется сильно связанная модель, которая поддерживает память, т. е. состояние объектов, и обеспечивается более эффективное взаимодействие объектов в среде. NET. При этом объекты располагаются на разных компьютерах и в разных процессорах.

При исследовании слабо и сильно связанных (Loosely Coupled и Tightly Coupled) моделей распределенных приложений нужно отметить, что модель Loosely Coupled, также как и Tightly Coupled, предназначена для распределенных приложений. Различие состоит в более свободном выборе протоколов и отношении к сохранению состояния, которое используется в последнем подходе. Loosely Coupled модель подразумевает построение распределенных приложений на основе минимального набора приложений и взаимодействий. Tightly Coupled подход подразумевает более жесткую связь, более строгую однородность частей приложения и в отличие от Loosely Coupled основан на заранее согласованных более строгих протоколах и наборах данных. Loosely Coupled подход использует стандартные протоколы XML и HTTP. Что касается модели взаимодействия объектов, то здесь распределенные объекты взаимодействуют без сохранения памяти о своей истории. Таким образом, с точки зрения ООП можно конкретизировать подход взаимодействия клиента и сервера без сохранения состояния тем, что каждый вызов метода обрабатывает новый экземпляр объекта, который создается заново. В отличие от похода, связанного с наличием состояния, не меняется состояние объекта со старого на новое, а просто создается новый экземпляр объекта.

Что касается работы с сетью, позднее мы увидим, каким образом это связано с пространством имен Remoting. Напомним, что существует пространство имен System, внутри которого находится пространство. NET, а потом —.Sockets (рис. 9.7). Первое подпространство определяет основные параметры источников взаимодействия, т. е. таких точек взаимодействия на клиенте и сервере, как пространство доменных имен, характеристики точек взаимодействия и т. д. И пространство имен Sockets определяет более детально характеристики клиента и сервера, которые связаны с конкретным протоколом, скажем TCP/IP, и построением потока данных для обмена сетевой информацией.

Рис. 9.7. Иерархия пространств имен

Глава 10
Технологии сетевого взаимодействия корпоративных систем

Рассмотрим эволюцию технологий сетевого взаимодействия распределенных приложений и построение такого рода приложений. Одной из наиболее ранних технологий является удаленный вызов процедур – Remote Procedure Call. Во многом эта технология реализуется в Remoting при маршеринге, который будет рассмотрен несколько позднее. Еще одним подходом была передача сообщений, т. е. взаимодействие между распределенным приложением, между объектами. В одном из первых вариантов она называлась DCE – Distributed Computing Environment. Если рассматривать взаимодействие клиента и сервера, концепция открытых систем предполагает явное распределение ролей на клиент и сервер. При этом клиент – это компьютер, который осуществляет преимущественно запрос информации, в данном случае это вызов функции, которая на самом деле обращается к серверу, хотя это очевидно только из ее названия. Сервер осуществляет поиск, получение и предоставление отчетной информации для клиента в соответствии с его запросом. Кроме того, вспоминая главу об архитектуре, заметим, что помимо двух слоев клиент-серверной архитектуры (клиента и сервера), существует еще промежуточный слой, который предназначен для локализации взаимодействия. Но пока рассмотрим уровни клиента и уровни сервера.

Идея взаимодействия состоит в том, что функция, которая в данном случае называется Server Func, формально при чтении кода не должна вызывать ассоциации с сервером. С точки зрения клиента, осуществляется как бы выполнение этой функции. Функция имеет два параметра – символьный Hello и целочисленный 123. И результат должен быть присвоен некоему объекту J. На самом деле на клиенте функционирует специальный слой, который называется промежуточным и транслирует при переводе этой программы в промежуточный код из так называемого верхнего слоя (Top Layer), представляющего собой исходный текст на том или ином языке программирования (в данном случае это язык С), который транслирует этот вызов в некий внутренний вызов и упаковывает его нужным образом. Этот специализированный механизм называется Proxy-клиент. Он осуществляет трансляцию и упаковку этого вызова процедуры в обращение к другому компьютеру (серверу) с нужными параметрами, которые переупаковываются, меняют свои имена. Происходит передача некоего указателя на область памяти (*str) и некоего целочисленного значения v, с кодом, который у нас имеется на клиенте, осуществляется передача его после соответствующей упаковки серверу, Stub серверу, т. е. специальный функциональный компонент сервера осуществляет преобразование этого запроса во внутренний запрос сервера, организацию процедуры, заданной клиентом, и активизацию этой процедуры на сервере с заданными параметрами. Вычисление значений с переданными аргументами происходит путем подстановки вместо параметров их значений. Вычисление связано с работой процедуры на сервере. После этого осуществляется обратная упаковка и передача клиенту в ответ на его запрос. На нижнем уровне (Bottom Layer) осуществляется передача данных по сети на соответствующем уровне. Ниже находятся все последующие протоколы сетевого стека.

В ходе обсуждения взаимодействия RPC – это один из весьма важных механизмов взаимодействия по сети, который принципиально важен для понимания технологии Remoting. Осуществляется взаимодействие между Proxy и Stub. Proxy – это подпрограмма, которую может вызывать клиент на сервере. Поэтому технология называется процедурой удаленного вызова. Proxy передает серверу запрос на вызов подпрограммы, которая работает на сервере, с заданными параметрами, и ждет ответа от сервера. После выполнения процедуры результат возвращается клиенту. При этом вызов Proxy с точки зрения кода клиента не отличается от вызова внутренней подпрограммы или метода. Фактически эта логика взаимодействия удаленного вызова инкапсулируется внутри Proxy. Аналогично, но только на сервере, работает технология, связанная со Stub. Это тот код, который выполняется на сервере. Он получает от клиента запрос на вызов заданной подпрограммы. Осуществляется вызов подпрограммы, которая работает на сервере, а не на клиенте, как кажется клиенту. И результат, который записывается в переменную Result, автоматически после упаковки отправляется по сети на клиент. При этом Proxy и Stub создаются автоматически. Для этого, конечно же, требуется определенного рода описание открытых интерфейсов, т. е. сред взаимодействия между клиентом и сервером. Одним из примеров такого языка является IDL–Interface Definition Language, который используется в технологии брокеров объектных запросов (COBRA).

Итак, мы можем видеть три слоя взаимодействия, если абстрагироваться от сетевого уровня, где все просто описано с точки зрения кода, на уровне исходного текста программ – процедура на клиенте и процедура на сервере. На уровне Middle Layer происходит упаковка Proxy Stub клиента и упаковка параметров, выполнение процедуры на сервере после распаковки и передача упакованного результата через Middle Layer на клиент. Собственно, данные передаются на уровне Bottom Layer по протоколу передачи данных. Естественно, существует стек сетевых протоколов с целым рядом протоколов, которые лежат ниже перечисленных нами уровней процедурного взаимодействия.

Посмотрим, как осуществлялась революция объектных методов RPC в 1990-е гг. При этом объекты могут быть реализованы разными средами разработки и написаны на разных языках программирования.

Объектное RPC скрывает различия между объектами, которые разработаны в разных интегрированных средах и, возможно, на разных языках. В связи с этим сделан большой шаг вперед по сравнению с предыдущим подходом, который на самом деле достаточно жестко завязан на язык программирования. И, конечно же, по сути, объектного взаимодействия в 1980-е гг. в полной мере еще не было. При этом наиболее распространенными подходами следует считать подходы, основанные на компонентной модели COM c динамическим расширением Decom и COM+. И второй важный подход – CORBA. Это альтернативный подход, связанный с брокерами объектных запросов и использующий язык IDL, который описывает интерфейсы взаимодействия между различными объектами. Подход CORBA связан с Object Request Broker, которые реализуют функции, несколько похожие на Proxy и Stub, описанные ранее.

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

Рис. 9.8. Клиент-серверное взаимодействие по схеме COBRA

Итак, какие особенности можно выявить в объектных RPC, объектном подходе к удаленному вызову процедур, с точки зрения взаимодействии Proxy и Stub по сравнению с ранним подходом? Речь идет об объектном взаимодействии. Proxy и Stub выглядят как обычные объекты. Для клиента функция на С выглядит как локальная. Так же и объект при вызове будет выглядеть как локальный объект на клиенте. Но на самом деле этот объект осуществляет упаковку параметров и передачу их серверу. Этот процесс упаковки параметров и их передачи называется маршаллинг и является весьма существенным для. NET и Remoting, так как по сути означает передачу объекта через границу процесса.

Маршаллинг включает упаковку параметра вызова и его передачу в упакованном формате от клиента к серверу. Анмаршаллинг соответственно включает распаковку параметра вызова и передачу распакованной функции или метода серверу, который и выполняет запрос. Затем осуществляются обратный процесс упаковки ответа, передача клиенту брокером этого ответа от сервера, и клиент осуществляет распаковку результата и приложение его вызывающей процедуре. Таким образом, процедуры маршаллинга и анмаршаллинга реализованы тоже полностью в объектном виде и, в частности, включают передачу параметра вызова, ряда других параметров и позволяют осуществить нейтральное взаимодействие относительно характеристик клиента и сервера. То есть клиент ничего не знает о сервере, деталях реализации объекта на сервере. С его точки зрения, речь идет просто об обработке некоего объекта, который хранится как бы локально. А сервер ничего не знает о клиенте, просто выполняет свою функцию.

Теперь обсудим, каким образом осуществляется взаимодействие между клиентом и сервером в RPC по объектной схеме. Как Proxy, так и Stub являются объектами и реализуют в полной мере объектно-ориентированное взаимодействие параметров Operation передачи от клиента серверу и параметров Reply возвращаемого значения от сервера клиенту. При этом взаимодействие между клиентом и сервером, кроме упаковки параметров и ответов, включает, что очень важно, передачу этих параметров через границу различных процессов (1 и 2), которые выполняются, возможно, в различных ОС или на различных машинах. Напомним, что процесс упаковки называется маршаллингом, процесс распаковки – анмаршаллингом. Если перейти от традиционной схемы объектно-ориентированного взаимодействия при реализации технологии удаленного вызова процедур RPC к той технологии, которая реализуется в среде Microsoft.NET и называется. NET Remoting, станет понятно, что взаимодействие организуется очень похоже.

Каким же образом осуществляется взаимодействие между клиентом и сервером через границы процессов и как при этом используются так называемые домены приложений? Рассмотрим это более подробно. При выполнении некоторой программы, написанной для. NET, естественно, следуя главе, в которой речь шла о среде. NET, выполнение это происходит в среде CLR. По сути, компоненты программ, которые реализуются и выполняются в этой среде, оттранслированы в код виртуальной машины. Microsoft Intermediate Language, зависящая от платформы, функционирует в терминах этого языка на той самой виртуальной машине, которая называется CLR машина. При этом загрузчик программы сначала создает хост CLR, по сути, экземпляр виртуальной машины и приложение машины, в которую по умолчанию загружаются сборки, необходимые для выполнения этой программы, и затем осуществляется передача управления этому процессу. В некоторых случаях в одном процессе может сосуществовать несколько различных доменов приложений. Среда CLR – виртуальная машина. NET может поддерживать независимое выполнение программ одного процесса в рамках нескольких доменов приложений. На рис. 9.9 представлен процесс, который на уровне операционной системы реализован в архитектуре приложений 32-разрядной машины Windows. При этом на уровне. NET осуществляется создание хоста CLR, в рамках которого могут функционировать в одном процессе несколько доменов приложений. Далее соотношение между процессами и доменами приложений выглядит следующим образом. В рамках одного и того же компьютера, скажем CLR, могут функционировать несколько процессов в архитектуре той же Windows 32. В каждом из них может быть также не один домен приложения, а несколько. Другой компьютер – это может быть сервер или другой клиент – также может иметь один или несколько процессов Windows 32, внутри которых также может быть несколько (в данном случае три) домена приложений.

Рассмотрим, каким образом осуществляется работа с удаленными объектами, расположенными на сервере? Со стороны клиента это выглядит точно так же, как и в среде. NET. Существует четкое разделение на взаимодействие по имени и взаимодействие по ссылке (Value и Reference). Если мы вспомним систему CPS, систему типизации, которая реализована для. NET, то увидим, что в рамках этой системы типизации существует изначальное четкое разграничение на две большие категории типов – Reference и Value. И обращение с объектами, обработка объектов этих больших категорий происходит различными способами. Напомним, что объекты классов категории Value, например, хранятся в стеке, при копировании создается физическая копия объекта, создается еще один объект стандартного размера, скажем, 4 или 2 байта, в зависимости от типа объекта. Он имеет фиксированный размер, и осуществляется физическое копирование значения. Если рассматривать объекты типа Reference, то осуществляется копирование ссылки, а не самого значения. Размер объекта, который имеет тип ссылку, изначально не определен, и на самом деле речь идем о том, что есть указатель на некую область памяти. Хранится в динамической памяти объект этого типа, т. е. взаимодействие между такого рода объектами, или маршаллинг, также происходит различными способами. То есть в. NET существует подход, который называется Marshal by Value и Marshal by Reference. Рассмотрим основные различия между этими подходами, а также их реализацию.

Рис. 9.9. Домены приложений в Windows

Примерно различие в обработке объектов такое же, как и различие между объектами-ссылками и объектами-значениями и их обработкой средой CLR. Если речь идет о маршаллинге по значению, то реализация процесса происходит следующим образом: от сервера клиенту необходимо передать объект целиком. Точно так же, как осуществляется физическое копирование объекта при присваивании, скажем, целочисленного значения (физическую копию объекта). Напомним, что несмотря на то, что существуют типы-ссылки и типы-значения, на верхнем уровне иерархии типов каждый тип является объектом и относится к пространству имен System.Object. И в связи с этим существует определенное единообразие. Но на уровне обработки существует фундаментальное различие между типами-ссылками и типами-значениями.

Итак, маршаллинг по значению разумен, целесообразен в тех случаях, когда, так же как и в случае объектов типа значения, речь идет о достаточно простых объектах – целочисленных, булевых или о тех объектах, которые редко претерпевают изменения во времени. Маршаллинг по ссылке предполагает передачу от сервера к клиенту параметров вызываемого метода, а не самого объекта. И методы объекта вызываются на стороне сервера. В случае маршаллинга по значению вызываются на стороне клиента, в случае маршаллинга по ссылке – на стороне сервера. В отношении маршаллинга по ссылке и по значению можно отметить следующую специфику: объект содержит ссылки на системные ресурсы, которые специфичны либо для процессора, либо для компьютера. Также объект содержит ссылки на большое количество других объектов на стороне сервера либо часто изменяет свое состояние. Если речь идет о маршаллинге по ссылке, то этот подход предпочтителен для сложных специфичных объектов конкретного процесса или компьютера, для объектов с большим количеством ссылок или для объектов, которые часто изменяют свое состояние. При работе с корпоративными системами также целесообразен маршаллинг по ссылке.

Рассмотрим явное создание объекта как вариант клиент-серверного взаимодействия по технологии Remoting. Здесь мы уже видим в примере кода, что явно используется метод маршаллинга объекта класса Remoting Services. То есть в пространстве имен. NET существует класс Remoting Services, который имеет ряд методов, связанных с реализацией объектов и передачей параметров от клиента серверу различными способами. Итак, при явном создании объекта осуществляется прежде всего создание некоего объекта, вызов конструктора, оператор NEW для объекта Obj класса Server Object. Осуществляется вызов конструктора без параметра, и создается новый объект. После чего осуществляется маршаллинг с явной передачей именно этого объекта путем вызова метода Marshal класса Remoting Services с параметром Obj. Таким образом, объект на сервере создается явно. Он будет иметь имя srv_obj. И объект на сервере существует до тех пор, пока на него имеются ссылки. Реализация уничтожения ссылок явным образом осуществляется посредством вызова специального метода, того же класса Remoting Services, который называется Disconnect. При этом необходимо явно указывать, что речь идет об объекте Obj.

При явном создании объекта клиент может получить ссылку на этот серверный объект двумя способами – используя либо метод Get Object класса Activator (здесь необходимо преобразование к классу Server Object), либо оператор type of, который определяет объект по типу. Для этого явно указывается имя объекта, которое было ранее определено и его местоположение, – Localhost. Другой подход связан с определением типа объекта и явным указанием этого объекта таким же образом, как и в предыдущем методе, а затем созданием объекта явным образом посредством конструктора Server Object.

Далее следует рассмотреть вопрос явной активизации объектов на сервере. Момент создания объекта в этом случае определяется сервером. При этом речь идет уже о передаче не экземпляра объекта, а его типа. То есть имя присваивается не экземпляру, а типу. И для обработки каждого вызова удаленного метода может создаваться собственно новый экземпляр объекта. При этом используется метод Single Call. Здесь явно указывается имя объекта srv_obj и осуществляется вызов метода Register Service Type, т. е. определенный метод реализации сервиса на основе класса Remoting Configuration. Нужно сказать, что все вызовы удаленного метода могут обрабатываться одним и тем же объектом, сервером, при этом используется метод Single в отличие от предыдущего Single Call. Клиент работает с удаленным объектом полностью аналогично предыдущему случаю. Другая форма взаимодействия между клиентом и сервером основана на активизации объектов клиента. При этом момент создания объекта определяется уже не сервером, а клиентом, и на сервере в этом случае может быть создано много объектов. В этом случае сервер объекта уникально однозначно определяется явным указанием имени компьютера. Мы видим, что осуществляется передача параметра методу Register Activated Service Type, т. е. осуществляется регистрация указанного типа сервиса с параметром того самого объекта типа «сервер», к которому реализуется обращение. При этом, по сути, мы работаем в том же пространстве имен Remoting с тем же классом Remoting Configuration, но другим образом определяем конфигурацию взаимодействия между клиентом и сервером. При активизации объектов клиентом на сервере клиент должен вначале осуществить регистрацию типа объекта с учетом его расположения на сервере, а затем создать объекты, для каждого обращения создается объект (Proxy), который осуществляет инкапсуляцию методов на сервере. Итак, мы используем метод Register Activator Client Type класса Remoting Configuration с явным указанием, что тип объекта расположен на сервере, и явным указанием этой машины. После чего для каждого вызова создается свой объект класса Server Object. По сути, это не совсем объекты, это Proxy. Но для каждого из них осуществляется свой вызов оператора New.

Последнее, что будет обсуждаться касательно Remoting, – это процедура сборки мусора. Вообще, процедура сборки мусора крайне важна для больших объектных систем. Здесь речь идет о том, что существует большое количество объектов типа «ссылки». Следует напомнить, что в. NET, в CTS – системе типизации, существуют два больших подкласса объектов – ссылки и значения. Если рассматривать корпоративные системы, то очевидно, что для реализации распределенных приложений, которые используют большое количество сложных объектов, а вместе с тем эти объекты имеют сложную структуру и динамически взаимодействуют друг с другом, целесообразно использовать типы-ссылки. В связи с этим часто возникают ситуации, когда не вполне корректно уничтожается информация о значении самого типа-ссылки при уничтожении собственно объекта этого типа. То есть не всегда разрывается связь между именем и значением объекта, на которое указывает ссылка с этого имени. Для уничтожения такого рода висячих ссылок, т. е. ссылок, указывающих на некорректную область памяти, которая уже освобождена и не содержит значения типа «ссылки», существует стандартный процесс сборки мусора.