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

Учебные программы » Сетевые технологии » Конспект лекций

Промежуточное ПО. Назначение, функции и виды 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:

  • асинхронные 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))

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

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

Message-oriented middleware

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  • CORBA (Common Object Request Broker Architecture, типовая архитектура брокера объектных запросов) — открытый стандарт, разработанный группой Object Management Group (OMG), который определяет интерфейсы между сетевыми объектами, позволяющие им работать совместно. Брокеры объектных запросов (object request brokers, ORB), созданные в соответствии с CORBA, представляют интерфейсы для разработки объектно-ориентированных систем «клиент-сервер».
  • Microsoft COM (Component Object Model, компонентная объектная модель) — это семейство технологий, предназначенных для организации взаимодействия Windows-приложений (см. MSDN: The Component Object Model). В это семейство входят COM+, DCOM (Distributed COM) и ActiveX Controls. Microsoft позиционирует COM как платформу для разработки повторно используемых (re-usable) компонентов приложений. В случае DCOM — компонентов распределенных клиент-серверных систем.
  • EJB (Enterprise JavaBeans) — технология, разработанная Sun Microsystems для корпоративных решений на платформе Java (Java EE/EJB). Спецификация EJB описывает архитектуру серверных компонентов и порядок их использования в клиент-серверных приложениях. Эта технология упрощает разработку распределенных систем на основе Java и обеспечивает наибольшую переносимость Java-приложений.

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

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

  • Собственное промежуточное ПО СУБД — это встроенные механизмы доступа для конкретного сервера баз данных.
  • Основное промежуточное ПО баз данных — к этому типу относится, например, интерфейс Open Database Connectivity (ODBC), который позволяет программам «общаться» на разных диалектах SQL через общие интерфейсы.

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

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

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

  • ODBC (Open DataBase Connectivity, открытое соединение с БД) — это интерфейс доступа к базам данных, разработанный Microsoft. ODBC представляет возможность обращения к реляционным и нереляционным СУБД в гетерогенной среде через унифицированные вызовы API (рис. 6). Обращения к функциям ODBC транслируются в естественные диалекты многих СУБД с помощью специальных ODBC-драйверов либо напрямую, либо через указание имени источника данных (рис. 7).
    ODBC в распределенной среде  ODBC: схема

    Рис. 6. а) Доступ к БД через ODBC; б) Интерфейс ODBC.

  • JDBC (Java DataBase Connectivity) — это прикладной программный интерфейс для обращения к базам данных из Java-приложений. Средства JDBC являются платформонезависимыми и выполняются в любой среде под управлением виртуальной машины Java. По сравнению с ODBC этот тип промежуточного ПО баз данных предлагает больше возможностей по интеграции приложений и расширяет сферу использования БД (например, в сторону мобильных приложений). Больше того, спецификация JDBC предусматривает возможность доступа Java-приложений к БД через ODBC с помощью специального средства, т.н. «моста» (ODBC/JDBC-bridge).
  • EDA (Event-Driven Architecture, событийно-управляемая архитектура) — это концепция управления корпоративной информационной системой на основе событий, возникающих в бизнес-процессе. Доступ к БД в EDA базируется на использовании централизованного способа обращения к распределенным базам данных. Все запросы клиентов поступают на вход SQL-шлюза, который транслирует SQL-запросы в унифицированный формат и перенаправляет их к серверам БД. Взаимодействие с ними возможно как через набор общих API, так и через ODBC-интерфейс (рис. 8). Использование SQL-шлюза обеспечивает доступ к данным в разнородных многозвенных системах, где множество приложений параллельно обращаются к источникам данных различного формата.
    EDA (Event-Driven Architecture): схема

    Рис. 8. Принцип доступа к БД в EDA

  • DQB (Distributed Query Broker, брокер распределенных запросов) — децентрализованное (в отличие от EDA) решение для доступа к БД на основе ORB. Заглушки-брокеры, размещенные на серверах БД, принимают унифицированные SQL-запросы и транслируют их в диалекты конкретных СУБД (рис. 9).
    DQBroker (Distributed Query Broker): схема

    Рис. 9. Брокер распределенных запросов (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.

Анатольев А.Г., 06.08.2013

Постоянный адрес этой страницы:

↑ В начало страницы