Удаленный вызов процедур. DCOM, CORBA.

Удаленный вызов процедур

Удаленный вызов процедур (англ. remote procedure call, RPC) — это технология взаимодействия прикладных программ, выполняющихся на разных узлах, разработанная корпорацией Sun Microsystems (см. RFC 1831). RPC дает возможность программам вызывать процедуры, расположенные на других узлах, (или в других адресных пространствах) точно так же, как и локальные процедуры.

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

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

В этой модели клиентский и серверный процессы выполняются синхронно — в каждый момент времени выполняется только один из них. Тем не менее, расширения протокола RPC (например, пакет ONC+ фирмы Sun Microsystems) допускают и асинхронный режим, когда клиентский процесс может выполнять некоторую полезную работу во время ожидания ответа.

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

Протокол RPC определяет только структуру сообщений и может быть реализован поверх любого транспортного протокола. Надежность RPC зависит от надежности транспортного протокола: при работе через TCP выполняется управление потоком, квитирование и повторная передача потерянных пакетов, при работе через UDP, программа, пользующаяся RPC, должна самостоятельно обеспечивать надежность. При этом возникает проблема единственного выполнения удаленной процедуры: если по тем или иным причинам от сервера не пришло сообщение-ответ, то, по истечении таймаута, клиент должен повторно передать сообщение-запрос. Возможна ситуация, при которой сервер получит и выполнит оба запроса, что является нарушением логики работы программы. Для защиты от подобных проблем может использоваться, например, механизм нумерации запросов: разные запросы несут в себе разные номера, а повторные запросы — номера исходных запросов. Сервер должен хранить список выполненных номеров запросов и не выполнять запросы повторно.

Спецификация RPC не определяет конкретную процедуру привязки (англ. binding) клиентов к серверам. Возможным способам привязки посвящен отдельный документ — RFC 1833. Конкретная служба (service) RPC идентифицируется номером программы RPC, номером ее версии и транспортным адресом, по которому к ней можно обратиться. Транспортный адрес состоит из сетевого адреса (например, IP-адреса) и селектора транспорта (например, номера TCP-порта). Для успешного обращения к службе, клиент должен знать все перечисленные идентификаторы. При этом номер программы RPC и номер ее версии обычно жестко прописываются в программе клиента, а сетевой адрес либо передается программе при запуске, либо определяется динамически путем обращения к службе имен (например, DNS). Селектор транспорта обычно определяется динамически при запуске экземпляра сервера. Сервер динамически выделяет транспортный адрес и сообщает его некоторой известной (расположенной по заранее заданному селектору транспорта) службе поиска (англ. lookup service). Клиенты, когда им нужно определить транспортный адрес той или иной службы, обращаются к службе поиска.

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

RFC 1833 определяет три типа служб поиска, все они используют общий номер программы RPC (1000000) и порты TCP/111 и UDP/111.

Стандарты распределенных вычислений Open Source Foundation (OSF) Distributed Computing Environment (DCE) используют RPC как основной механизм выполнения удаленных процедур. В пользу RPC говорят его простота, прозрачность и производительность. То, что модель вызова RPC максимально приближена к модели вызова локальных процедур, позволяет сократить время обучения разработчиков.

Microsoft DCOM

Модель распределенных компонентных объектов DCOM (англ. Distributed Component Object Model) — объектно-ориентированная технология разработки распределенных программных систем.

Хотя технология COM (англ. Component Object Model) разрабатывалась с учетом будущей поддержки распределенных систем, однако ее первоначальная реализация могла работать только на одном компьютере. Объекты СОМ могли быть реализованы в DLL или в отдельном процессе, исполняющемся только на том же компьютере, что и их клиент. В DCOM объекты могут предоставлять свои сервисы и клиентам, выполняющимся на других узлах сети.

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

Сервисы создания объектов — одни из важнейших сервисов предоставляемых СОМ. Клиенты обычно создают объекты, вызывая библиотеку СОМ или через моникеры. Эти подходы работают и в DCOM, хотя и с некоторыми новыми особенностями.

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

DCOM предоставляет несколько вариантов идентификации узлов в зависимости от используемых сетевых протоколов: доменные имена (DNS), IP-адреса, имена NetBIOS, IPX-адреса.

После запуска удаленного объекта и получения указателей на его интерфейсы, клиент может вызывать методы этих интерфейсов. Вызов метода объекта, реализованного в удаленном сервере, сводится к вызову удаленной процедуры сервера по протоколу объектного RPC (англ. Object RPC). Хотя ORPC включает ряд новых соглашений по взаимодействию клиента с сервером, добавляет несколько новых типов данных и использует некоторые поля пакета особым образом, сама структура пакетов осталась той же, что и в оригинальном DCE RPC.

MS RPC определяет два протокола, из которых выбирается один в зависимости от используемого транспортного протокола. Протокол CN используется поверх транспортных протоколов с установлением логических соединений, например, TCP, надеясь на то, что нижележащий протокол гарантирует надежную доставку данных. Протокол DG используется поверх транспортных протоколов без установления логического соединения, например, UDP. Протокол DG самостоятельно обеспечивает надежную доставку данных.

Для выполнения вызова ORPC, клиент должен указать сетевой адрес удаленного узла (например, IP-адрес), номер порта и комбинацию протоколов (например, CL RPC и UDP).

Для минимизации риска неавторизованного создания и использования объектов, DCOM определяет стандартный способ доступа к сервисам защиты и их использования. Контроль над тем, кто имеет право запускать серверы различных классов на данном удаленном узле, в DCOM называется защитой активизации (англ. activation security). Контроль прав на вызовы клиентами методов уже исполняющихся объектов, в DCOM называется защитой вызовов (англ. call security).

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

Интерфейсы защиты вызовов DCOM определяют 2 основные возможности: автоматическую и поинтерфейсную защиты. В первом случае клиентский или серверный процесс вызовом функции CoInitializeSecurity устанавливает уровень защиты по умолчанию для всех вызовов этого процесса или вызовов, выполняемых им. Во втором — разные установки защиты можно задать для разных интерфейсов одного объекта или для разных объектов. Можно использовать и оба варианта одновременно, установив значения по умолчанию с помощью автоматической защиты и выполнив затем тонкую настройку, используя поинтерфейсную защиту.

Технология CORBA

Общая архитектура брокера объектных запросов CORBA (англ. Common Object Request Broker Architecture) — технология, архитектура и набор стандартов для создания распределенных программных приложений на базе использования брокеров объектных запросов ORB (англ. Object Request Broker) для взаимодействия распределенных объектов.

Спецификации CORBA разработаны международным консорциумом OMG (англ. Object Management Group), основной задачей которого является разработка архитектуры и методов реализации программного обеспечения, которое в объектно-ориентированном стиле позволило бы выполнить интеграцию существующих и заново разрабатываемых (не обязательно объектно-ориентированных) информационно-вычислительных ресурсов. Эти ресурсы должны быть оформлены в виде CORBA-объектов, обменивающихся запросами и ответами с другими объектами. Для каждого объекта должен быть описан его интерфейс — набор запросов, на которые этот объект умеет отвечать. Описание интерфейса объекта на языке определения интерфейсов IDL (англ. Interface Definition Language) обрабатывается специальным компилятором, на выходе которого появляется программный код, отвечающий за взаимодействие объекта с брокером ORB. Этот программный код затем встраивается в серванта (англ. servant — слуга) — серверную программу, реализующую объект.

Инфраструктуру CORBA составляют взаимодействующие программные процессы брокеров ORB, объектные службы (англ. object services) и общие средства (англ. common facilities).

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

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

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