Книга: C# для профессионалов. Том II

Обзор .NET Remoting

Обзор .NET Remoting

.NET Remoting может использоваться для доступа к объектам в домене другого приложения независимо от того, находятся ли два объекта внутри одного процесса, в разных процессах или на разных системах.

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

Приложения .NET работают внутри домена приложения. Домен приложения можно рассматривать как подпроцесс внутри процесса, Традиционно процессы используются как изолирующая граница. Приложение, выполняющееся в одном процессе, не может получить доступ и разрушить память в другом процессе. Чтобы приложения общались друг с другом, требуется межпроцессная коммуникация. При использовании .NET домен приложения выступает новой границей безопасности внутри процесса, так как код CIL является проверяемым и обеспечивает безопасность типов данных. Различные приложения могут выполняться внутри одного процесса, но внутри различных доменов приложений. Объекты внутри одного домена приложений могут взаимодействовать напрямую. Чтобы получить доступ к объектам в другом домене приложений, требуется прокси.

Прежде чем перейти к внутренней функциональности .NET Remoting, давайте рассмотрим основные элементы архитектуры:

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

? Канал используется для коммуникации между клиентом и сервером. Существует клиентская и серверная часть канала. С помощью .NET Framework мы получаем два типа каналов, которые общаются через TCP или HTTP. Можно также создать специальный канал, который поддерживает связь с помощью другого протокола.

? Сообщения посылаются в канал. Они создаются для коммуникации между клиентом и сервером и хранят информацию об удаленных объектах, именах вызванных методов и всех аргументах.

? Форматтер определяет, как сообщения передаются в канал. Вместе с .NET Framework мы получаем форматтеры SOAP и двоичный. Форматтер SOAP можно использовать для коммуникации со службами Web, которые не основываются на .NET Framework. Двоичные форматтеры действуют значительно быстрее и могут эффективно использоваться в среде интранет. Конечно, имеется возможность создать специальный форматтер.

? Провайдер форматтера используется для соединения форматтера с каналом. Создавая канал, можно выбрать провайдер форматтера, и этот выбор в свою очередь, определяет форматтер, который будет использоваться для передачи данных в канал.

? Клиент вызывает методы на прокси, а не на удаленном объекте. Существует два типа прокси: прозрачный прокси и реальный прокси. Прозрачный прокси выглядит для клиента как удаленный объект. Клиент может вызывать методы, реализуемые удаленным объектом на прозрачном прокси. В свою очередь, прозрачный прокси вызывает метод Invoke() на реальном прокси. Метод Invoke() использует приемник сообщений для передачи сообщения в канал.

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

? Клиент может использовать активатор для создания удаленного объекта на сервере или для получения прокси активированного сервером объекта.

? RemotingConfiguration является служебным классом для конфигурирования удаленных серверов и клиентов. Этот класс используется для чтения конфигурационных файлов или для динамического конфигурирования удаленных объектов.

? ChannelServices является служебным классом для регистрации каналов и затем — для отправки сообщений в канал.

Чтобы получить представление о функциональности, давайте рассмотрим концептуально, как элементы сочетаются друг с другом.

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

Прозрачный прокси, в свою очередь, вызывает реальный прокси. Реальный прокси отвечает за отправку сообщения в канал. Реальный прокси является подключаемым, можно заменить его с помощью специальной реализации, которая применяется для записи журнала для другого способа поиска канала и т.д. Используемая по умолчанию реализация реального прокси находит совокупность (или цепочку) уполномоченных приемников и передает сообщение в первый уполномоченный приемник. Уполномоченный приемник может перехватить и изменить сообщение. Примерами таких приемников являются приемники отладки, системы безопасности, синхронизации. Последний уполномоченный приемник досылает сообщение в канал. Как сообщение передается по линиям связи, зависит от форматтера. Ранее уже упоминалось, что имеются SOAP и двоичный форматтеры, которые также являются подключаемыми. Канал отвечает либо за соединение с принимающим сокетом на сервере, либо за отправку форматированных данных. Со специальным каналом можно производить различные действия, необходимые для передачи данных на другую сторону.

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

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

Оглавление книги