Удалённый вызов процедур (иногда вызов удалённых процедур; RPC от англ. remote procedure call) — класс технологий, позволяющих программам вызывать функции или процедуры в другом адресном пространстве (на удалённых узлах либо в независимой сторонней системе на том же узле). Обычно реализация RPC-технологии включает два компонента: сетевой протокол для обмена в режиме клиент-сервер и язык сериализации объектов (или структур для необъектных RPC). Различные реализации имеют отличающуюся друг от друга архитектуру и разнятся в возможностях: одни реализуют архитектуру SOA, другие — CORBA или DCOM. На транспортном уровне RPC используют в основном протоколы TCP и UDP, однако, некоторые построены на основе HTTP.
Существует множество технологий, обеспечивающих RPC, среди них:
- DCE/RPC — двоичный протокол на базе различных транспортных протоколов, в том числе TCP/IP и Named Pipes из протокола SMB/CIFS;
- DCOM — объектно-ориентированное расширение DCE/RPC, позволяющее передавать ссылки на объекты и вызывать методы объектов через таковые ссылки;
- Microsoft RPC;
- gRPC;
- ZeroC ICE;
- JSON-RPC — текстовый протокол на базе HTTP[1]
- .NET Remoting — двоичный протокол на базе TCP, UDP, HTTP;
- Java RMI — вызов удалённых методов для платформы Java[2];
- SOAP — текстовый протокол на базе HTTP[3];
- Sun RPC — двоичный протокол на базе TCP и UDP и XDR[4], второе название — ONC RPC[5];
- XML RPC — текстовый протокол на базе HTTP[6].
Принцип
правитьИдея вызова удалённых процедур состоит в расширении механизма передачи управления и данных внутри программы, выполняющейся на одном узле, на передачу управления и данных через сеть. Средства удалённого вызова процедур предназначены для облегчения организации распределённых вычислений и создания распределенных клиент-серверных информационных систем. Наибольшая эффективность использования RPC достигается в тех приложениях, в которых существует интерактивная связь между удалёнными компонентами с небольшим временем ответов и относительно малым количеством передаваемых данных. Такие приложения называются RPC-ориентированными.
Характерными чертами вызова удалённых процедур являются:
- асимметричность, то есть одна из взаимодействующих сторон является инициатором;
- синхронность, то есть выполнение вызывающей процедуры приостанавливается с момента выдачи запроса и возобновляется только после возврата из вызываемой процедуры.
Реализация удалённых вызовов существенно сложнее реализации вызовов локальных процедур.
Так как вызывающая и вызываемая процедуры выполняются на разных узлах, то они имеют разные адресные пространства, и это создает проблемы при передаче параметров и результатов, особенно если машины находятся под управлением различных операционных систем или имеют различную архитектуру (например, используется прямой или обратный порядок байтов). Так как RPC не может рассчитывать на разделяемую память, то это означает, что параметры RPC не должны содержать указателей на ячейки нестековой памяти и что значения параметров должны копироваться с одного компьютера на другой. Для копирования параметров процедуры и результата выполнения через сеть выполняется их сериализация.
В отличие от локального вызова удалённый вызов процедур обязательно использует транспортный уровень сетевой архитектуры (например TCP), однако это остается скрытым от разработчика. Кроме того, в реализации RPC участвуют как минимум два процесса — по одному на каждом узле, и в случае, если один из них аварийно завершится, могут возникнуть следующие ситуации: при аварии вызывающей процедуры удалённо вызванные процедуры станут «осиротевшими», а при аварийном завершении удалённых процедур станут «обездоленными родителями» вызывающие процедуры, которые будут безрезультатно ожидать ответа от удалённых процедур.
Также существует ряд проблем, связанных с неоднородностью языков программирования и операционных сред: структуры данных и структуры вызова процедур, поддерживаемые в каком-либо одном языке программирования, не поддерживаются точно так же во всех других языках. Таким образом имеется проблема совместимости, до сих пор не решённая ни с помощью введения одного общепринятого стандарта, ни с помощью реализации нескольких конкурирующих стандартов на всех архитектурах и во всех языках.
Компоненты
правитьЦентральное место в реализациях RPC занимает транспортная подсистема, отвечающая за управление исходящими и входящими соединениями. В её функции входит поддержка понятия «граница сообщения» для транспортных протоколов, не поддерживающих его непосредственно (TCP) и поддержка гарантированной доставки для транспортных протоколов, её не поддерживающих (UDP).
Компонент пулирования потоков (только для вызываемой стороны) — предоставляет контекст выполнения для вызванного по сети кода.
Компонент маршалинга (аналог «сериализации») обеспечивает упаковку параметров вызовов в поток байт стандартным образом, не зависящим от архитектуры (в частности, от порядка байт в слове). В частности, ему могут подвергаться массивы, строки и структуры, на которые указывают параметры-указатели.
Отдельный компонент может отвечать за шифрование пакетов и наложение на них цифровой подписи.
Отдельный блок функций — аутентификация и авторизация, обеспечиващие передачу по сети информации, идентифицирующей субъект, осуществляющий вызов.
В некоторых реализациях RPC (.NET Remoting) границы подсистем являются открытыми полиморфными интерфейсами, и возможно написать свою реализацию почти всех перечисленных подсистем. В других реализациях (DCE RPC в Windows) это не так.
Примечания
править- ↑ RFC-4627. Дата обращения: 13 ноября 2008. Архивировано 1 января 2016 года.
- ↑ JDK 5.0 Remote Method Invocation (RMI)-related APIs & Developer Guides - from Sun Microsystems. Дата обращения: 13 ноября 2008. Архивировано 19 декабря 2008 года.
- ↑ RFC-4227
- ↑ RFC-1831. Дата обращения: 13 ноября 2008. Архивировано 6 ноября 2008 года.
- ↑ RFC-1833. Дата обращения: 13 ноября 2008. Архивировано 25 октября 2008 года.
- ↑ RFC-3529. Дата обращения: 13 ноября 2008. Архивировано 10 октября 2008 года.
Ссылки
правитьДля улучшения этой статьи желательно:
|