2.2 Модели взаимодействия компонентов рс
Ключевым сервисом промежуточной среды для создания РС является обеспечение обмена данными между компонентами распределенной системы. В настоящий момент существуют две концепции взаимодействия программных компонент:
1) обмен сообщениями между компонентами;
2) и вызов процедур или методов объекта удаленной компоненты по аналогии с локальным вызовом процедуры.
Поскольку в настоящее время любое взаимодействие между удаленными компонентами в конечном итоге основано на сокетах TCP/IP, первичным с точки зрения промежуточной среды является низкоуровневый обмен сообщениями на основе сетевых сокетов, сервис которых никак не определяет формат передаваемого сообщения. На базе протоколов TCP или HTTP затем могут быть построены прикладные протоколы обмена сообщений более высокого уровня абстракции для реализации более сложного обмена сообщениями или удаленного вызова процедур.
Удаленный вызов является моделью, происходящей от языков программирования высокого уровня, а не от реализации интерфейса транспортного уровня сетевых протоколов. Поэтому протоколы удаленного вызова должны обязательно базироваться на какой-либо системе передачи сообщений, включая как непосредственное использование сокетов TCP/IP, так и основанные на нем другие промежуточные среды для обмена сообщениями. Реализация высокоуровневых служб обмена сообщениями, в свою очередь, может использовать удаленный вызов процедур, основанный на более низкоуровневой передаче сообщений, использующей, например, непосредственно сетевые сокеты. Таким образом, одна промежуточная среда может использовать для своего функционирования сервисы другой промежуточной среды, аналогично тому, как один протокол транспортного или сетевого уровня может работать поверх другого протокола.
2.2.1 Обмен сообщениями
Явный обмен сообщениями между процессами является основой многих РС.
Существует два метода передачи сообщений от одной удаленной системы к другой – непосредственный обмен сообщениями и использование очередей сообщений. В первом случае передача происходит напрямую, и она возможна только в том случае, если принимающая сторона готова принять сообщение в этот же момент времени.
Во втором случае используется посредник – менеджер очередей сообщений. Компонент посылает сообщение в одну из очередей менеджера, после чего он может продолжить свою работу. В дальнейшем получающая сторона извлечет сообщение из очереди менеджера и приступит к его обработке.
Простейшей реализацией непосредственного обмена сообщениями является использование транспортного уровня сети через интерфейс сокетов, минуя какое-либо промежуточное программное обеспечение. Однако такой способ взаимодействия обычно не применяется в системах автоматизации предприятия, поскольку в этом случае реализация всех функций промежуточной среды ложится на разработчиков приложения. При таком подходе сложно получить расширяемую и надежную распределенную систему, поэтому для разработки прикладных распределенных систем обычно используются системы очередей сообщений.
Существует несколько разработок в области промежуточного программного обеспечения, реализующие высокоуровневые сервисы для обмена сообщениями между программными компонентами. К ним относятся, в частности, Microsoft Message Queuing, IBM MQSeries и Sun Java System Message Queue. Такие системы дают возможность приложениям использовать следующие базовые примитивы по использованию очередей:
– добавить сообщение в очередь;
– взять первое сообщение из очереди, процесс блокируется до появления в очереди хотя бы одного сообщения;
– проверить очередь на наличие сообщений;
- установить обработчик, вызываемый при появлении сообщений в очереди.
Менеджер очереди сообщений в таких системах может находиться на компьютере, отличном от компьютеров с участвующими в обмене компонентами. В этом случае сообщение первоначально помещается в исходящую очередь на компьютере с посылающей сообщения компонентой, а затем пересылается менеджеру требуемой.
Для создания крупных систем обмена сообщениями может использоваться маршрутизация сообщений, при которой сообщения не передаются напрямую менеджеру, поддерживающему очередь, а проходят через ряд промежуточных менеджеров очередей сообщений (рис. 2.1).
Рис. 2.1. Системы очередей сообщений
Использование очередей сообщений ориентировано на асинхронный обмен данными.
Основные достоинства таких систем:
– время функционирования сервера может быть не связано со временем работы клиентов;
– независимость промежуточной среды от средства разработки компонент и используемого языка программирования;
– считывать и обрабатывать заявки из очереди могут несколько независимых компонент, что дает возможность достаточно просто создавать устойчивые и масштабируемые системы.
Недостатки систем очередей сообщений являются продолжением их достоинств:
– необходимость явного использования очередей распределенным приложением;
- сложность реализации синхронного обмена;
– определенные накладные расходы на использование менеджеров очередей;
– сложность получение ответа: передача ответа может потребовать отдельной
- очереди на каждый компонент, посылающий заявки.