Сергей Зыков - Основы проектирования корпоративных систем

В ходе обсуждения взаимодействия 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, станет понятно, что взаимодействие организуется очень похоже.