Лекции по дисциплине: «Компьютерные сети и сетевые технологии» По специальности: 1304033 «Вычислительная техника и программное обеспечение»



бет28/37
Дата07.01.2022
өлшемі0,67 Mb.
#17346
түріЛекции
1   ...   24   25   26   27   28   29   30   31   ...   37
Байланысты:
Сетевые технологии, 3

8.1.Виды промежуточного ПО


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

  1. Программное обеспечение для межпрограммного взаимодействия (см. также IPC - Inter-Process Communication).

  2. Программное обеспечение доступа к базам данных.

Протоколы и продукты этой категории облегчают межпроцессные взаимодействия (IPC - InterProcess Communications) и распределение объектов в инфраструктуре корпоративной информационной системы. Они выполняют роль клея, позволяющего соединить многозвенные приложения. Основными технологиями являются следующие: RPC, MOM, TPM и ORB. В готовых решениях, как правило, используется один или несколько таких протоколов.

Концепция вызова удаленных процедур (remote procedure call — RPC) была разработана и реализована в компанией XEROX еще начале 80-х годов XX века. Общий смысл RPC можно представить так: программа может выполнять не только собственные (скомпилированные) процедуры и функции, но и обращаться к процедурам удаленного сервера (рис. 2).





Рис. 2. Вызов удаленных процедур

Для установки связи, передачи вызова и возврата результата клиентский и серверный процессы обращаются к специальным компонентам – «заглушкам», соответственно клиентской и серверной (client stub и server stub). Эти stub'ы не реализуют никакой прикладной логики и предназначены только для организации взаимодействия удаленных (в общем случае) приложений. Все RPC-обращения клиента (имена функций и списки параметров) упаковываются клиентской заглушкой в сетевые сообщения (этот процесс называется marshaling) и ей же передаются серверной заглушке. Та, в свою очередь, распаковывает полученные данные (unmarshaling), передает их реальной функции сервера, а полученные результаты упаковывает в обратном порядке. Клиентская заглушка принимает ответ, распаковывает его и возвращает в приложение. Таким образом, процедуры-заглушки изолируют прикладные модули клиента и сервера от уровня сетевых коммуникаций.

Для определения правил, задающих отношения между клиентом и сервером 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))



Достарыңызбен бөлісу:
1   ...   24   25   26   27   28   29   30   31   ...   37




©emirsaba.org 2024
әкімшілігінің қараңыз

    Басты бет