7.3.2. Методы удаленного вызова процедур

7.3.2. Методы удаленного вызова процедур

Несмотря немногочисленные исключения, такие как NFS (Network File System) и проект GNOM€, попытки заимствовать технологии CORBA, ASN.1 и другие формы интерфейса удаленного вызова процедур в основном провалились. Данные технологии не прижились в Unix-культуре.

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

Существует еще одна проблема: интерфейсы, имеющие более развитые сигнатуры типов, также стремятся к большей сложности, а следовательно, являются более неустойчивыми. С течением времени происходит нарушение их онтологии, по мере того как ассортимент типов, проходящих через интерфейсы, неуклонно растет, а отдельные типы становятся более сложными. Нарушение онтологии становится проблемой, поскольку несогласованность структур более вероятна, чем несогласованность строк. Если онтология программ с каждой стороны не совпадает, то значительно затрудняется взаимодействие данных программы и устранение ошибок. Наиболее успешными RPC-приложениями (такими как Network File System) являются те, в которых прикладная область изначально имеет только несколько простых типов данных.

Обычным аргументом в пользу RPC является то, что данная технология допускает использование "более развитых" интерфейсов, чем методы, подобные текстовым потокам, — т.е. таких интерфейсов, в которых онтология типов данных является более сложной и специфичной для прикладной задачи. Однако нельзя забывать о правиле простоты. В главе 4 отмечалось, что одной из функций интерфейсов является создание заслонок, препятствующих взаимному проникновению деталей внутренней реализации модулей. Следовательно, главный аргумент в пользу RPC также является аргументом, подтверждающим возрастание глобальной сложности, вместо того, чтобы минимизировать ее.

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

Технологии СОМ и DCOM в Windows являются, возможно, основными примерами того, насколько это может быть плохо, но существует множество других примеров. Компания Apple отказалась от технологии OpenDoc, a CORBA и однажды широко разрекламированная методика Java RMI исчезли с горизонта Unix, как только люди приобрели практический опыт работы с ними. Это вполне возможно, поскольку данные методы фактически решают не больше проблем, чем создают.

Эндрю С. Таненбаум (Andrew S. Tanenbaum) и Роберт ван Ренесс (Robbert van Renesse) подробно проанализировали общую проблему в статье "A Critique of the Remote Procedure Call Paradigm" [83J, которая должна послужить строгим предостережением для тех, кто рассматривает возможность использования архитектуры, основанной на методиках RPC.

Все описанные проблемы могут обусловить долгосрочные трудности для сравнительно небольшого числа Unix-проектов, в которых используются RPC-методы. Среди таких проектов наиболее известным, вероятно, является GNOME55. Данные проблемы также вносят свой вклад в печально известные уязвимости незащищенных NFS-серверов.

С другой стороны, в мире Unix строго придерживаются прозрачных и воспринимаемых интерфейсов. Это одна из сил в основе непреходящей преданности Unix-культуры IPC-механизмам на основе текстовых протоколов. Часто утверждают, что издержки синтаксического анализа текстовых протоколов являются проблемой производительности по сравнению с двоичными RPC-протоколами, но RPC-интерфейсы склонны иметь проблемы задержек, которые представляются гораздо худшими, поскольку (а) невозможно без усилий заранее предсказать количество операций марша-линга и демаршалинга, которое будет задействовано определенным вызовом, и (b) RPC-модель поощряет программистов рассматривать сетевые транзакции как бесплатные. Добавление даже одного дополнительного обхода в интерфейс транзакции, как правило, добавляет сетевую задержку, достаточную для того, чтобы превысить любые издержки, связанные с синтаксическим анализом или маршалингом.

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

В настоящее время такие протоколы (XML-RPC и SOAP) являются интересным способом слияния RPC-методов и текстовых потоков в Unix. Протоколы XML-RPC и SOAP, будучи текстовыми и прозрачными, более приемлемы для Unix-программистов, чем небезопасные и тяжеловесные двоичные форматы сериализа-ции, на смену которым они приходят. Несмотря на то, что они не решают всех глобальных проблем, указанных Танденбаумом и ван Ренессом, они действительно отчасти комбинируют преимущества текстовых потоков и RPC-методов.

Поделитесь на страничке

Следующая глава >

Похожие главы из других книг

Программирование с помощью таймеров обратного вызова

Из книги Язык программирования С# 2005 и платформа .NET 2.0. [3-е издание] автора Троелсен Эндрю

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


Поддержка синхронного вызова

Из книги Искусство программирования для Unix автора Реймонд Эрик Стивен

Поддержка синхронного вызова Генерируемый агент определяет также поддержку синхронного вызова Web-методов. Например, синхронный вариант метода Subtract() реализуется так.public int Subtract(int x, int y) { object[] results = this.invoke("Subtract", new object[] {x, y}); return ((int)(results[0]));}Обратите внимание на то, что


Поддержка асинхронного вызова

Из книги UNIX: взаимодействие процессов автора Стивенс Уильям Ричард

Поддержка асинхронного вызова Поддержка асинхронного вызова Web-методов в .NET 2.0 сильно изменилась по сравнению с .NET 1.x. По своему предыдущему опыту вы можете знать, что агенты .NET 1.1 использовали методы BeginXXX()/EndXXX() для вызова Web-методов во вторичном потоке выполнения.


7.3.2. Методы удаленного вызова процедур

Из книги Системное программирование в среде Windows автора Харт Джонсон М

7.3.2. Методы удаленного вызова процедур Несмотря немногочисленные исключения, такие как NFS (Network File System) и проект GNOM€, попытки заимствовать технологии CORBA, ASN.1 и другие формы интерфейса удаленного вызова процедур в основном провалились. Данные технологии не прижились в


Непрерываемость системного вызова door_call

Из книги О чём не пишут в книгах по Delphi автора Григорьев А. Б.

Непрерываемость системного вызова door_call Документация на door_call предупреждает, что эта функция не предполагает возможности перезапуска (библиотечная функция door_call делает системный вызов с тем же именем). Мы можем убедиться в этом, изменив процедуру сервера таким образом,


Использование дейтаграмм для удаленного вызова процедур

Из книги VBA для чайников автора Каммингс Стив

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


1.1.5. Функции обратного вызова

Из книги C++. Сборник рецептов автора Диггинс Кристофер

1.1.5. Функции обратного вызова Прежде чем двигаться дальше, необходимо разобраться с тем, что такое функции обратного вызова (callback functions: этот термин иногда также переводят "функции косвенного вызова"). Эти функции в программе описываются, но обычно не вызываются напрямую,


Отличия процедур типа Function от процедур типа Sub

Из книги Атака на Internet автора Медведовский Илья Давыдович

Отличия процедур типа Function от процедур типа Sub Между процедурами типа Function и типа Sub есть одно существенное отличие: в процедуре типа Function обязательно где-то должен присутствовать по крайней мере один оператор, задающий значение этой функции. При этом используется имя


15.1. Применение указателей функций для их обратного вызова

Из книги Linux программирование в примерах автора Роббинс Арнольд

15.1. Применение указателей функций для их обратного вызова ПроблемаПланируется использование некоторой функции func1, которая на этапе выполнения должна вызывать другую функцию func2. Однако по той или иной причине нельзя внутри функции func1 жестко закодировать имя функции


Глава 5 Методы удаленного сканирования портов

Из книги Операционная система UNIX автора Робачевский Андрей М.

Глава 5 Методы удаленного сканирования портов Все тайное становится явным. Рассмотрим существующие на сегодняшний день различные методы сетевого сканирования. Для этого необходимо ответить на следующий вопрос: «Что такое сканирование портов, и для чего оно


Семантика вызова

Из книги Разработка ядра Linux автора Лав Роберт

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


15.5. Оператор вызова функции

Из книги автора

15.5. Оператор вызова функции Оператор вызова функции может быть перегружен для объектов типа класса. (Мы уже видели, как он используется, при рассмотрении объектов-функций в разделе 12.3.) Если определен класс, представляющий некоторую операцию, то для ее вызова


18.5.3. Порядок вызова конструкторов и деструкторов

Из книги автора

18.5.3. Порядок вызова конструкторов и деструкторов Виртуальные базовые классы всегда конструируются перед невиртуальными, вне зависимости от их расположения в иерархии наследования. Например, в приведенной иерархии у класса TeddyBear (плюшевый мишка) есть два виртуальных


Определение необходимого системного вызова

Из книги автора

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


Контекст системного вызова

Из книги автора

Контекст системного вызова Как уже обсуждалось в главе 3, "Управление процессами", при выполнении системного вызова ядро работает в контексте процесса. Указатель current указывает на текущее задание, которое и есть процессом, выполняющим системный вызов.В контексте процесса