Промежуточное ПО межпрограммного взаимодействия

Промежуточное ПО. Назначение, функции и виды middleware.

Промежуточное программное обеспечение используется в многозвенных клиент-серверных приложениях для интеграции распределенных компонентов в единую информационную систему.

Эволюция архитектуры «клиент-сервер»

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

ограниченные возможности масштабирования;
необходимость изменения клиентских приложений при изменении работы серверной логики.

Решить эти проблемы позволяет переход на трех- и многозвенные модели, в которых прикладная логика вынесена в отдельный уровень (на сервер приложений). Это позволяет эффективно распределять нагрузку и обеспечить прозрачное наращивание как функциональности сервера (серверов) приложений, так и числа обслуживаемых пользователей.

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

Определение и назначение промежуточного ПО

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

Рис. 1. Промежуточное программное обеспечение

{Термин middleware впервые был использован в 1968 г., но как технология интеграции корпоративных приложений, этот тип программного обеспечения стал использоваться с 80-х годов XX в. для решения проблем совместимости и взаимодействия новых приложений с устаревшими наследованными системами.

Место промежуточного ПО — в условной «середине» между сетевыми приложениями или их компонентами. Этим оно напоминает среднее звено в трехзвенных клиент-серверных архитектурах, за исключением того, что функциональные части middleware распределены между приложениями и/или их компонентами в корпоративной сетевой среде.}

Функции middleware

Сервисы middleware представляют приложениям разнобразные функции API, которые, в сравнении с функциями операционных систем и сетевых служб, обеспечивают:

прозрачный доступ к другим сетевым сервисам и приложениям;
независимость от других сетевых сервисов;
высокую надежность и постоянную готовность.

Следует отметить, что зачастую различия в функциональности операционной системы и промежуточного ПО являются условными. В частности, некоторые возможности, ранее представляемые исключительно средствами middleware, теперь реализуются на уровне ядра операционных систем. Типичным примером является стек TCP/IP, поддержка которого включена практически во все ОС.

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

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

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

Промежуточное ПО межпрограммного взаимодействия

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

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

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

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

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

У RPC как средства организации сетевого взаимодействия есть ряд минусов, кроющихся в самой парадигме структурного программирования:

Синхронные запросы — RPC приостанавливает выполнение приложения до тех пор, пока сервер не вернет требуемые данные.
Статические отношения между компонентами — привязка клиентского процесса к серверным заглушкам происходит на этапе компиляции и не может быть изменена во время выполнения.

Для устранения этих недостатков были разработаны более совершенные механизмы реализации RPC:

асинхронные RPC, позволяющие избежать приостановки выполнения клиентского приложения посредством функций обратного вызова (call-backfunctions);
код заглушек вынесен в динамически подключаемые библиотеки.

Протокол взаимодействия 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))

Сервисы обработки сообщений (MOM — message-orientedmiddleware) —это системы, как правило асинхронные, в которых взаимодействие между клиентом и сервером основано на обмене сообщениями. Сообщения — это текстовые блоки, состоящие из управляющих команд и передаваемых данных. Для передачи сообщений используются байт-ориентированные протоколы, такие как HTTP, POP/SMTP и т.п.

Обмен сообщениями реализуется через API системы MOM. Запросы сервисов ставятся в очередь сообщений и обрабатываются в соответствии с приоритетами и доступностью ресурсов (рис. 3). Приоритеты сообщений позволяют обеспечить первоочередную доставку важных сообщений, а отложенная доставка осуществляется либо по расписанию, либо при появлении адресата в сети. Ответы сервера содержат информацию об успешном или неуспешном выполнении операции.

Рис. 3. Промежуточное обеспечение, ориентированное на обработку сообщений (MOM)

Сервисы MOM хорошо зарекомендовали себя в сильно распределенных приложениях, используемых в гетерогенной сети с медленными и ненадежными соединениями. Это, во-многом, достигается благодаря поддержке уровней «качества обслуживания»:

надежная доставка сообщений (reliablemessagedelivery) — система MOM гарантирует, что в процессе обмена ни одно сообщение не будет утеряно;
гарантированная доставка сообщений (guaranteedmessagedelivery) — сообщение доставляется адресату немедленно или через заданный промежуток времени, не превышающий определенного значения (в случае, если сеть в данный момент не доступна);
застрахованная доставка сообщений (assuredmessagedelivery) — каждое сообщение доставляется только один раз.

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

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

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

Сервисы MOM, обслуживающие клиентов по подписке/публикации (publish&subscribe) работают по принципу, напоминающему почтовую рассылку: одно приложение публикует информацию в сети, а другие подписываются на эту публикацию для получения необходимых данных. Взаимодействующие таким способом приложения полностью независимы друг от друга, что представляет возможности динамической реконфигурации всей распределенной системы.

Мониторы обработки транзакций (TransactionProcessingmonitors, TP-monitors) — это промежуточное программное обеспечение, обеспечивающее контроль передачи данных от клиента при работе с распределенными базами данных. Монитор транзакций обеспечивает целостность данных, следя за тем, чтобы не было потерянных или незавершенных транзакций. Транзакция – это законченный блок обращений к базе данных, для которого гарантируется выполнение четырех условий ACID:

Атомарность (Atomicity) – операции транзакции образуют неделимый, атомарный блок, который либо выполняется от начала до конца, либо не выполняется вообще. При невозможности выполнения транзакции происходит откат к исходному состоянию;
Согласованность (Consistency) – по завершении транзакции все задействованные ресурсы находятся в предопределенном и согласованном состоянии;
Изолированность (Isolation) – одновременный доступ транзакций различных приложений к разделяемым ресурсам координируется таким образом, чтобы исключить их влияние друг на друга;
Долговременность (Durability) – все модификации ресурсов в процессе выполнения транзакции будут долговременными.

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

Рис. 4. Монитор транзакций

Подробное описание открытой спецификации Distributed TP доступно на сайте OpenGroup.

Распределенные объектные системы (Distributedobjectsystems) — это промежуточное программное обеспечение, реализованное в виде взаимодействующих друг с другом программных объектов. Каждый такой объект уникальным образом идентифицируется в сети и обеспечивает доступ к представляемым им сервисам через публичные свойства и методы. Реализация объекта и платформа, на которой он выполняется, полностью прозрачны для клиента.

С точки зрения разработки, использование распределенных объектов оправданно при создании масштабных объектно-ориентированных систем. Фактически же, объектная «обертка» таких решений скрывает за собой ранее рассмотренные RPC, MOM и средства управления транзакциями. По-этому, в первом приближении общий принцип взаимодействия распределенных объектов очень похож на RPC (рис. 5). Это сходство заметно и в средствах описания интерфейсов — объекты используют все тот же IDL. Однако, в сравнении с RPC, распределенные объекты могут компоноваться динамически, т.е. не на этапе компиляции, а во время выполнения приложений.

Рис. 5. Распределенные объектные системы (stub и skeleton - клиентская и серверная заглушки)

Архитектура распределенных объектных систем стандартизована и наиболее распространены спецификации CORBA, COM/DCOM и EJB.

Дата добавления: 2018-05-12; просмотров: 601; Мы поможем в написании вашей работы!

Поделиться с друзьями:

12 Следующая ⇒

Мы поможем в написании ваших работ!