Обычным аргументом в пользу RPC является то, что данная технология допускает использование "более развитых" интерфейсов, чем методы, подобные текстовым потокам, — т.е. таких интерфейсов, в которых онтология типов данных является более сложной и специфичной для прикладной задачи. Однако нельзя забывать о правиле простоты. В главе 4 отмечалось, что одной из функций интерфейсов является создание заслонок, препятствующих взаимному проникновению деталей внутренней реализации модулей. Следовательно, главный аргумент в пользу RPC также является аргументом, подтверждающим возрастание глобальной сложности, вместо того, чтобы минимизировать ее.
RPC представляется методикой, которая поощряет создание крупных, причудливых, перепроектированных систем с неясными интерфейсами, высокой глобальной сложностью и серьезными проблемами надежности и перекоса версий — идеальный пример неуправляемых громоздких связующих уровней.
Технологии COM и DCOM в Windows являются, возможно, основными примерами того, насколько это может быть плохо, но существует множество других примеров. Компания Apple отказалась от технологии OpenDoc, a CORBA и однажды широко разрекламированная методика Java RMI исчезли с горизонта Unix, как только люди приобрели практический опыт работы с ними. Это вполне возможно, поскольку данные методы фактически решают не больше проблем, чем создают.
Эндрю С. Таненбаум (Andrew S. Tanenbaum) и Роберт ван Ренесс (Robbert van Renesse) подробно проанализировали общую проблему в статье "A Critique of the Remote Procedure Call Paradigm" [83], которая должна послужить строгим предостережением для тех, кто рассматривает возможность использования архитектуры, основанной на методиках RPC.
Все описанные проблемы могут обусловить долгосрочные трудности для сравнительно небольшого числа Unix-проектов, в которых используются RPC-методы. Среди таких проектов наиболее известным, вероятно, является GNOME[75]. Данные проблемы также вносят свой вклад в печально известные уязвимости незащищенных NFS-серверов.
С другой стороны, в мире Unix строго придерживаются прозрачных и воспринимаемых интерфейсов. Это одна из сил в основе непреходящей преданности Unix-культуры IPC-механизмам на основе текстовых протоколов. Часто утверждают, что издержки синтаксического анализа текстовых протоколов являются проблемой производительности по сравнению с двоичными RPC-протоколами, но RPC-интерфейсы склонны иметь проблемы задержек, которые представляются гораздо худшими, поскольку (а) невозможно без усилий заранее предсказать количество операций маршалинга и демаршалинга, которое будет задействовано определенным вызовом, и (b) RPC-модель поощряет программистов рассматривать сетевые транзакции как бесплатные. Добавление даже одного дополнительного обхода в интерфейс транзакции, как правило, добавляет сетевую задержку, достаточную для того, чтобы превысить любые издержки, связанные с синтаксическим анализом или маршалингом.
Даже если текстовые потоки были бы менее эффективными, чем RPC, потери производительности были бы незначительными и линейными, а такую проблему лучше решать с помощью модернизации аппаратного обеспечения, чем путем увеличения времени разработки или внесения дополнительной архитектурной сложности. Все потери производительности при использовании текстовых потоков, компенсируются благодаря возможности разрабатывать менее сложные системы, которые упрощают мониторинг, моделирование и понимание.
В настоящее время такие протоколы (XML-RPC и SOAP) являются интересным способом слияния RPC-методов и текстовых потоков в Unix. Протоколы XML-RPC и SOAP, будучи текстовыми и прозрачными, более приемлемы для Unix-программистов, чем небезопасные и тяжеловесные двоичные форматы сериализации, на смену которым они приходят. Несмотря на то, что они не решают всех глобальных проблем, указанных Танненбаумом и ван Ренессом, они действительно отчасти комбинируют преимущества текстовых потоков и RPC-методов.
7.3.3. Опасны ли параллельные процессы?
Хотя Unix-разработчики давно привыкли к вычислениям с помощью взаимодействующих процессов, среди них нет собственной традиции использования параллельных процессов (процессов, которые совместно используют все выделенное им адресное пространство). Параллельные процессы представляют собой недавнее заимствование извне, и тот факт, что Unix-программисты обычно испытывают к ним неприязнь, не является просто случайностью или исторически непредвиденным поворотом событий.
75
Разработчики основного конкурирующего с GNOME пакета KDE вначале использовали технологию CORBA, но отказались от нес в версии 2.0. С тех пор они ищут более легковесные IPC-методы.