Виды промежуточного по
Востребованность промежуточного ПО при разработке и внедрении сложных систем привела к появлению различных типов middleware, которые отличаются масштабируемостью, надежностью и самой идеей организации взаимодействия. При этом весь существующий на сегодняшний день спектр промежуточного ПО можно условно разделить на две основных категории (по специализации):
Программное обеспечение для межпрограммного взаимодействия (см. также IPC - Inter-Process Communication).
Программное обеспечение доступа к базам данных.
Промежуточное по межпрограммного взаимодействия
Протоколы и продукты этой категории облегчают межпроцессные взаимодействия (IPC - InterProcess Communications) и распределение объектов в инфраструктуре корпоративной информационной системы. Они выполняют роль клея, позволяющего соединить многозвенные приложения. Основными технологиями являются следующие: RPC, MOM, TPM и ORB. В готовых решениях, как правило, используется один или несколько таких протоколов.
Вызов удаленных процедур
Рис. 2. Вызов удаленных процедур
Концепция вызова удаленных процедур (remote procedure call — RPC) была разработана и реализована в компанией XEROX еще начале 80-х годов XX века. Общий смысл RPC можно представить так: программа может выполнять не только собственные (скомпилированные) процедуры и функции, но и обращаться к процедурам удаленного сервера (рис. 2).
Для установки связи, передачи вызова и возврата результата клиентский и серверный процессы обращаются к специальным компонентам – «заглушкам», соответственно клиентской и серверной (client stub и server stub). Эти stub'ы не реализуют никакой прикладной логики и предназначены только для организации взаимодействия удаленных (в общем случае) приложений. Все RPC-обращения клиента (имена функций и списки параметров) упаковываются клиентской заглушкой в сетевые сообщения (этот процесс называется marshaling) и ей же передаются серверной заглушке. Та, в свою очередь, распаковывает полученные данные (unmarshaling), передает их реальной функции сервера, а полученные результаты упаковывает в обратном порядке. Клиентская заглушка принимает ответ, распаковывает его и возвращает в приложение. Таким образом, процедуры-заглушки изолируют прикладные модули клиента и сервера от уровня сетевых коммуникаций.
В этом случае вызов удаленной процедуры осуществляется миллион раз и на каждой итерации циклов будут выполняться операции по установлению соединения между клиентом и сервером, передаче данных и разрыву соединения. Это приведет к существенной нагрузке на сеть и снижению производительности системы. Правильнее в этом случае обеспечить возможность управления соединением вне тела циклов, что противоречит самой идее RPC.
Для определения правил, задающих отношения между клиентом и сервером RPC, используется язык описания интерфейсов IDL. Интерфейс содержит определение имени функции и полное описание передаваемых параметров и результатов выполнения. Правила IDL обеспечивают независимость механизма RPC от языков программирования: обращаясь к удаленной процедуре, клиент использует свои языковые конструкции, а IDL-компилятор преобразует их в унифицированные описания, понятные серверу. На сервере IDL-описания преобразуются в конструкции языка программирования, на котором реализован серверный процесс.
У RPC как средства организации сетевого взаимодействия есть ряд минусов, кроющихся в самой парадигме структурного программирования:
Синхронные запросы — RPC приостанавливает выполнение приложения до тех пор, пока сервер не вернет требуемые данные.
Статические отношения между компонентами — привязка клиентского процесса к серверным заглушкам происходит на этапе компиляции и не может быть изменена во время выполнения.
Для устранения этих недостатков были разработаны более совершенные механизмы реализации RPC:
асинхронные RPC, позволяющие избежать приостановки выполнения клиентского приложения посредством функций обратного вызова (call-back functions);
код заглушек вынесен в динамически подключаемые библиотеки.
Протокол взаимодействия RPC также может повлиять на работу системы. Рассмотрим гипотетический фрагмент кода:
for (i = 0, i < 1000, i++)
for (j = 0, j < 1000, j++)
RPC_call();
В этом случае вызов удаленной процедуры будет выполняться миллион раз. На каждой итерации будут выполняться действия не только по передаче данных и результатов, но и по управлению соединением. Это приведет не только к повышению нагрузки на сеть, но и снижению производительности системы в целом. В данном случае правильным решением является вынос функций установления и разрыва соединения за тело циклов, что противоречит самой идее RPC.
См. также: RFC 1057 Remote Procedure Call Protocol Specification Version 2 (Sun Microsystems), C706 DCE 1.1: Remote Procedure Call (The OpenGroup Distributed Computing Environment (DCE))