3.2. Архитектура .Net Remoting
В настоящее время все большее распространение получают распределенные приложения. В распределенном приложении (distributed application) отдельные компоненты выполняются на различных компьютерах, которые связаны сетью передачи данных. Как правило, компонент распределенного приложения реализует некий сервис, иначе говоря, предоставляет определенные услуги, доступные путем вызова методов компонента. Сам компонент является объектом некоторого класса. Таким образом, создание распределенного приложения подразумевает возможность вызова на одном компьютере методов объекта, размещенного на другом компьютере.
Введем некоторые термины, которые используются в дальнейшем. Рассматривая распределенное приложение, будем выделять клиент и сервер. Сервер содержит удаленные компоненты, клиент пользуется данными компонентами. Компонентам соответствуют классы. Эти классы будем называть удаленными классами (по отношению к клиенту), а объекты удаленных классов – удаленными объектами.
Для вызова методов удаленных объектов и клиент и сервер могут использовать традиционные подходы сетевого программирования. А именно:
Клиент должен обеспечить соединение с сервером и передачу серверу в закодированном виде имени класса, имени метода и параметров метода.
Сервер организует прослушивание сообщений от клиентов и их обработку (желательно в отдельных потоках выполнения).
Обработка сообщений клиентов подразумевает декодирование имени метода и параметров, фактический вызов соответствующего метода, кодирование результата и отправку его клиенту.
Клиент принимает закодированные результаты, декодирует их и возвращает как результат вызова метода.
Предложенное решение обладает рядом существенных недостатков, главный из которых – отсутствие гибкости. Также отметим возможные проблемы, связанные со временем существования удаленных объектов, обработкой исключительных ситуаций и т. п.
Технологии, подобные .NET Remoting1 (далее для краткости – Remoting), служат универсальным средством для организации работы с удаленными объектами. Remoting тесно интегрирована с исполняющей средой .NET Framework, а также предоставляет множество средств для тонкой настройки своей инфраструктуры.
Рассмотрим основные элементы Remoting, показанные на рисунке 6.
Рис. 6. Основные элементы архитектуры Remoting
Первый элемент архитектуры Remoting – это объект-заместитель или прокси-объект (proxy object). Прокси-объект выполняет следующие задачи. Во-первых, для клиентского кода он выглядит так же, как и любой объект локального класса, что упрощает клиентский код. Во-вторых, все вызовы методов прокси-объект превращает в специальные объекты-сообщения. Сообщение служит для описания метода. Оно, в частности, содержит имя метода, коллекцию входных и выходных параметров. Для того чтобы исполняющая среда (CLR) могла правильно создать прокси-объект, удаленный класс должен быть наследником (прямым или косвенным) класса System.MarshalByRefObject. В дальнейшем подобные классы будем для краткости называть MBR-классами. Кроме этого, клиентскому коду требуется для работы метаданные удаленного класса. Обычно для этого в удаленном классе выделяют интерфейс, который разделяют между сервером и клиентом.
Сообщение, сгенерированное прокси-объектом, попадает в канал (channel). Канал осуществляет коммуникацию между компьютерами по определенному протоколу. Стандартными каналами являются HTTP-канал и TCP-канал (входят в поставку Remoting). При необходимости можно реализовать собственный канал передачи.
С каналом могут быть связаны канальные приемники, при помощи которых осуществляется перехват сообщений. Обязательным элементом канала является форматер (formatter). Задача форматера – сериализовать сообщение, то есть представить его в виде потока данных. В составе Remoting имеется бинарный форматер и SOAP-форматер1. HTTP-канал использует по умолчанию SOAP-форматер, TCP-канал – бинарный форматер. При необходимости можно реализовать и собственный форматер данных и канальные приемники. Так как форматер выполняет сериализацию объекта-сообщения, то типы, представляющие входные и выходные параметры метода, должны быть сериализуемыми.
На стороне сервера форматер выполняет десериализацию потока данных из канала, а специальный диспетчер находит и вызывает требуемый метод с указанными фактическими параметрами. Затем диспетчер формирует сообщение с результатами работы метода и передает его в серверный канал. Далее это сообщение попадает в форматер на клиенте, десериализуется, а прокси-объект преобразует сообщение в выходное значение метода.
Такова в общих чертах архитектура Remoting. Отметим, что данная технология является расширяемой. В частности, как уже было сказано, пользователь при желании может реализовать собственные форматеры, каналы и канальные приемники, а также предоставлять собственные прокси-объекты вместо стандартных.