Учебно-методические материалы для студентов кафедры АСОИУ

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

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

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

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

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

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

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

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

Middleware - промежуточное ПО

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

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

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

Функции middleware

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

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

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

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

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

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

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

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

RPC - вызов удаленных процедур

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

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

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

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

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

Протокол взаимодействия 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-oriented middleware) —это системы, как правило асинхронные, в которых взаимодействие между клиентом и сервером основано на обмене сообщениями. Сообщения — это текстовые блоки, состоящие из управляющих команд и передаваемых данных. Для передачи сообщений используются байт-ориентированные протоколы, такие как HTTP, POP/SMTP и т.п.

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

Message-oriented middleware

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

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

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

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

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

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

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

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

Монитор транзакций

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

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

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

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

Распределенные объекты: stub + skeleton

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

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

Промежуточное ПО доступа к базам данных

Рассмотрим два основных типа промежуточного обеспечения, ориентированного на работу с распределенными данными — это собственное промежуточное обеспечение СУБД и основное промежуточное обеспечение баз данных.

Собственное промежуточное ПО СУБД. К этому виду относится, в первую очередь, поддержка стандартов языка SQL. Несмотря на то, что SQL является международным стандартом, разработчики СУБД самостоятельно определяют, какие из возможностей SQL они будут поддерживать в своих системах. В результате, конкретная СУБД может, с одной стороны, не поддерживать или поддерживать частично некоторые команды SQL, а с другой — представлять разработчикам приложений нестандартные языковые расширения.

Другим видом собственного middleware являются встроенные средства СУБД, позволяющие выполнять импорт данных из внешних источников (например, из других СУБД или текстовых файлов) и экспортировать данные в сторонние форматы (например, CSV или XML).

Основное промежуточное ПО доступа к БД. К этой категории относятся внешние (по отношению к СУБД) средства middleware, специально разработанные для обращения к базам данных. Сюда относятся как технологические решения (например, ODBC и JDBC), так и концептуальные, представляющие обобщенную архитектуру информационной системы с распределенными БД (например, EDA или DQB).

Middleware: Что выбрать?

Стек протоколов TCP/IP давно уже поддерживается на уровне операционных систем, средства RPC также доступны в сетевых ОС едва ли не "по умолчанию". Этот механизм практически не требует от разработчиков и интеграторов каких-либо новых знаний и навыков. Не требуется изучать специфические middleware API: вызов удаленной процедуры ничем не отличается от обращения к локальной подпрограмме, а все процессы преобразования данных и передачи их по сети выполняются клиентской и серверной заглушками. Использование RPC может быть наиболее подходящим решением для систем, где возможные проблемы, связанные с синхронностью протокола RPC, не являются критичными.

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

Взаимодействие компонентов корпоративных приложений в объектно-ориентированной среде удобнее всего реализовывать с помощью объектных-же средств промежуточного ПО. В этом случае, разработчик использует объектную модель, четко описывающую бизнес-процессы. Высокий уровень абстракции объектов (будь то ORB или EJB) полностью скрывает от пользователя детали реализации взаимодействия между ними. Использование объектов позволяет строить корпоративные приложения словно лего город, из унифицированных «кирпичиков»объектов. Это справедливо, если вся система является объектно-ориентированной. Затруднения с использованием распределенных объектов появляются, когда компонентами автоматированной системы являются унаследованные приложения.

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

Рассмотренные категории промежуточного ПО все реже и реже используются в «чистом» виде. Напротив, как и в большинстве сетевых технологий, развитие middleware идет в сторону объединения возможностей разных его категорий и для разного рода задач всегда можно подобрать наиболее подходящее решение.

Контрольные вопросы

  1. Опишите назначение промежуточного ПО.
  2. Перечислите основные способы организации межпрограммного взаимодействия (типы промежуточного ПО).
  3. Опишите принцип работы промежуточного ПО типа «сервис обмена сообщениями».
  4. Опишите принцип работы сервиса удаленного вызова процедур (RPC).
  5. Опишите принцип работы промежуточного ПО типа «монитор транзакций».
  6. Опишите принцип межпрограммного взаимодействия на основе объектной модели ORB.

CC-BY-CA Анатольев А.Г., 31.01.2012