Архитектура удаленного взаимодействия платформы .NET Framework

Этот раздел относится к технологии прежних версий, которая сохраняется для обеспечения обратной совместимости с существующими приложениями и не рекомендуется для разработки новых приложений. Сейчас распределенные приложения следует создавать с помощью  Windows Communication Foundation (WCF).

Инфраструктура удаленного взаимодействия платформы .NET представляет собой абстрактный подход к межпроцессному взаимодействию. Объекты, которые могут передаваться по значению или копироваться, автоматически передаются между приложениями в различных доменах приложений или на разных компьютерах. Для использования этих механизмов необходимо пометить пользовательские классы как сериализуемые.

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

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

Копии и ссылки

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

В то же время многие объекты невозможно или нерационально копировать и перемещать в другие процессы для выполнения. Объекты очень большого размера, у которых есть много методов, не следует копировать или передавать по значению в другие процессы. Обычно клиенту требуется только информация, возвращаемая одним или несколькими методами серверного объекта. Копирование всего серверного объекта, включая большие объемы внутренней информации или исполняемые структуры, не связанные с запросом клиента, приведет к нерациональному использованию полосы пропускания канала, памяти клиента и времени обработки. Кроме того, многие объекты предоставляют открытые методы, но для выполнения внутренних операций им могут требоваться закрытые данные. Копирование таких объектов может позволить несанкционированным клиентам проанализировать внутренние данные, что может создать риски информационной безопасности. Наконец, в некоторых объектах используются данные, которые невозможно скопировать ни одним из реалистичных способов. Например, в объекте FileInfo может содержаться ссылка на файл операционной системы, которая представляет собой уникальный адрес в памяти серверного процесса. Можно скопировать этот адрес, но он не будет допустимым в рамках другого процесса.

В таких случаях серверный процесс должен передавать клиентскому процессу ссылку на серверный объект, а не копию объекта. Клиенты могут использовать данную ссылку для вызова серверного объекта. Эти вызовы не выполняются в клиентском процессе. Вместо этого система удаленного взаимодействия собирает все сведения о вызове и отправляет их серверному процессу, который интерпретирует полученные сведения, обнаруживает необходимый серверный объект и выполняет вызов серверного объекта от имени клиентского объекта. Результаты вызова отправляются клиентскому процессу, чтобы вернуть их клиенту. Пропускная способность канала используется только для передачи необходимой информации: вызова, аргументов вызова, возвращаемых значений и исключений.

Упрощенное представление архитектуры удаленного взаимодействия

Основным принципом архитектуры удаленного взаимодействия является использование ссылок на объекты для взаимодействия серверных и клиентских объектов. Вместе с тем, архитектура удаленного взаимодействия предоставляет программистам более простую процедуру. Если клиент настроен надлежащим образом, достаточно создать новый экземпляр удаленного объекта с использованием ключевого слова new (или функции создания экземпляра в используемом языке программирования). Клиент получит ссылку на серверный объект, и программа сможет вызывать методы объекта так, как будто он существует в рамках текущего процесса, а не находится на другом компьютере. Чтобы создать ощущение, что серверный объект располагается в клиентском процессе, система удаленного взаимодействия использует объекты прокси. Прокси — это объекты, которые представляют какие-либо другие объекты. Когда клиент создает экземпляр удаленного типа, инфраструктура удаленного взаимодействия создает объект прокси, который является копией удаленного типа для клиента. Клиент вызывает метод объекта прокси, система удаленного взаимодействия получает вызов, направляет его в серверный процесс, вызывает серверный объект и передает возвращаемое значение клиентскому прокси, который возвращает результат клиенту.

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

Канал представляет собой тип, который получает поток данных, создает пакет в соответствии с требованиями определенного сетевого протокола и отправляет пакет другому компьютеру. Некоторые каналы могут только получать информацию, другие — только отправлять информацию, но есть и каналы, включая существующие по умолчанию классы TcpChannel и HttpChannel, которые могут использоваться для передачи данных в обоих направлениях.

Хотя серверный процесс располагает полной информацией обо всех типах, клиент знает только то, что ему требуется ссылка на объект в другом домене приложения, возможно, на другом компьютере. Для указания объекта извне домена приложения сервера используется URL-адрес. URL-адреса, представляющие уникальные типы для внешних доменов приложений, являются URL-адресами активации, которые обеспечивают обработку удаленного вызова надлежащим типом. Дополнительные сведения см. в разделе URL-адреса активации.

Полная архитектура системы удаленного взаимодействия

Предположим, что существует приложение, функционирующее на одном компьютере, и требуется использовать имеющуюся функциональность для обработки типа, хранящегося на другом компьютере. Общая схема процесса удаленного взаимодействия показана на следующем рисунке.

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

Для выполнения этих операций требуется очень небольшой объем кода, но необходимо уделить внимание проектированию и настройке взаимодействия. Код может быть абсолютно корректным и все же не работать, поскольку неверно указан URL-адрес или номер порта. Дополнительные сведения см. в разделе Конфигурация.

Хотя этот высокоуровневый обзор процесса удаленного взаимодействия выглядит несложно, детали более низкого уровня могут быть достаточно сложными. Более подробное обсуждение основных элементов удаленного взаимодействия приведено в других разделах, которые перечислены в разделе «См. также».

См. также

Основные понятия

Границы. Процессы и домены приложений
Объекты, поддерживающие и не поддерживающие удаленное взаимодействие
Каналы
Безопасность удаленного взаимодействия
Конфигурация удаленных приложений

Другие ресурсы

Общие сведения о средствах удаленного взаимодействия платформы .NET Framework
Активация и время существования объектов