Влияние исследований на технологию промежуточного программного обеспечения

Вольфганг Эммерих, Микио Аояма, Джо Свентек
Перевод: Сергей Кузнецов

Назад Содержание Вперёд

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

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

В статье Oxford English Dictionary, посвященной этимологии термина «промежуточное программное обеспечение» (middleware), в качестве первого литературного источника упоминается издание 1970 г. Dictionary of Computers [29], в котором промежуточное программное обеспечение определяется как «программное обеспечение производителей компьютеров, которое приспосабливается под конкретные потребности установки». Определение промежуточного программного обеспечения, которое используется в настоящее время, впервые появилось в статье, опубликованной 7 апреля 1972 г. в журнале Accountant. В статье говорилось следующее: «Сравнительно новый термин «промежуточное программное обеспечение» был введен по той причине, что при достижении некоторыми системами исключительной сложности потребовались усовершенствования и модификации стандартных операционных систем; программы, осуществляющие требуемые действия, назвали промежуточным программным обеспечением, поскольку они являются посредниками между операционной системой и прикладными программами». Популярность термину в компьютерной литературе принесла статья в CACM [16]. Сегодня промежуточное программное обеспечение понимается как слой между сетевыми операционными системами и приложениями, который помогает справляться с неоднородностью и распределенностью [16, 48]. В распределенной системе могут иметься один или несколько компонентов на одном или нескольких хостах. Чтобы система представала в виде интегрированного компьютерного средства, эти компоненты должны поддерживать взаимные коммуникации. Теоретически компоненты могли бы общаться с использованием примитивов, обеспечиваемых непосредственно сетевой операционной системой. На практике это слишком сложно, поскольку программистам приложений пришлось бы синхронизовать коммуникации между распределенными компонентами, выполняемыми в параллель, преобразовывать структуры данных уровня приложения в потоки байтов или дейтаграммы, которые можно передавать на основе сетевых транспортных протоколов, и справляться с неоднородностью представления данных на разных компьютерных архитектурах. Основная роль промежуточного программного обеспечения состоит в упрощении этих задач и обеспечении уместных абстракций, используемых программистами приложений при построении взаимодействующих компонентов распределенных систем. Определим теперь наиболее успешные абстракции, широко поддерживаемые в продуктах промежуточного программного обеспечения.

Рис. 4. Промежуточное программное обеспечение в распределенной системе (увеличить)

Первой ключевой абстракцией промежуточного программного обеспечения, которая была определена в литературе по распределенным системам, являлись вызовы удаленных процедур (Remote Procedure Calls, RPC). Основная идея удаленного вызова процедуры состоит в том, чтобы обеспечить программистам приложений возможность вызова процедуры, которая развернута и выполняется на некотором удаленном хосте, таким же образом, как если бы вызывалась локальная процедура. Для обеспечения этой возможности система поддержки удаленных вызовов процедур должна решать ряд задач. Во-первых, система RPC должна отображать сложные типы данных уровня приложения, передаваемые в качестве аргументов вызова и результатов, в транспортное представление, которое может передаваться с использованием основанных на потоках байтов или дейтаграммах транспортных протокольных примитивов, обычно поддерживаемых в сетевых операционных системах. В литературе этот процесс отображения называется маршалингом (marshalling). Во-вторых, от системы RPC может понадобиться преобразовывать представления данных, поскольку нельзя предполагать, что на клиенте и сервере будут использоваться одни и те же аппаратура, операционная система и язык программирования. Например, для алфавитно-цифровых данных могут использоваться разные кодировки, такие как ASCII или ECBDIC; на мейнфреймах для представления длинных числовых данных может использоваться прямой порядок байт в машинном слове, а в персональных компьютерах используются представления с обратным порядком байт; в разных языках программирования по-разному представляются символьные строки и т.д. Проблема неоднородности данных в системах RPC обычно разрешается за счет отображения в некоторый стандартизованный последовательный формат, иногда называемый также стандартизованным представлением данных. В-третьих, клиент, производящий вызов удаленной процедуры, и сервер, выполняющий эту процедуру, обычно выполняются в параллель. Чтобы воспроизвести поведение вызовов локальных процедур, при которых вызывающая программа блокируется до завершения вызванной процедуры, компонент синхронизации системы RPC блокирует клиента до тех пор, пока удаленная процедура успешно не завершится или не закончится аварийным образом. Наконец, по причине наличия нескольких точек управления, распределенные системы часто подвергаются сбоям. Поэтому в системах RPC должна определяться развитая семантика сбойных ситуаций.

Рис. 5. Архитектура системы RPC

На рис. 5 показаны общие аспекты архитектуры большинства систем RPC. Центральным архитектурным элементом являются стабы (stub), выполняющие синхронизацию, маршалинг, отображение в стандартизованное представление данных и сетевые коммуникации. Эти стабы иногда также называют посредниками (proxy), поскольку они представляют собой посредников серверных объектов для клиентов и посредников клиентских объектов для серверов. Одним из ключевых выводов, полученных при использовании ранних систем RPC, являлось то, что стабы трудно создавать вручную, впоследствии стала распространенной их автоматическая генерация. В системах RPC обычно используется некоторая разновидность языка определения интерфейсов (interface definition language, IDL), который используется для определения сигнатур удаленных процедур. В состав систем RPC входит компилятор IDL, используемый для автоматической генерации стабов. При использовании некоторых подходов язык определения интерфейсов может быть отделен от языка программирования, и в этом случае для языка программирования должны быть определены правила привязки (binding), указывающие, как в языке программирования представляются примитивы языка IDL.

Поскольку системы RPC появились первыми, их ключевые принципы, наиболее существенным из которых является синхронный вызов операции в удаленном хосте, повторно использовались в различных средах. В качестве объектно-ориентированных расширений систем RPC были определены объектные распределенные системы, и их языки определения интерфейсов включают примитивы для представления наследования, управления исключительными ситуациями, отложенного связывания и полиморфизма. Вызов удаленной операции в распределенной объектной системе часто называют запросом объекта (object request). В современных языках программирования, таких как Java, исконно поддерживаются вызовы удаленных методов (remote method invocation, RMI), в которых, по существу, воспроизводятся методы RPC по отношению к методам, выполняемым в другой виртуальной Java-машине. Наконец, Web-сервисы снова, по существу, основаны на идеях RPC, но для определения языка представления интерфейсов и стандартизованного представления данных используется XML.

В то время как механизм вызовов удаленных процедур завоевывал популярность, разработчикам приложений требовалось создавать надежные, отказоустойчивые и параллельно используемые системы. Ключевой абстракцией, содействующей в этом отношении, является понятие распределенной транзакции. Распределенные транзакции – это последовательности нескольких вызовов удаленных процедур, являющиеся атомарными (atomic), согласованными (consistent), изолированными (isolated) и долговечными (durable). Ранее транзакции были определены и использовались [60] в системах управления базами данных, но для поддержки распределенных транзакций требуется промежуточное программное обеспечение, которое иногда называют мониторами обработки транзакций (transaction processing monitors, TPM) [15]. В этих TPM реализуется двухфазный протокол фиксации, который позволяет транзакционным менеджерам ресурсов, таких как базы данных или очереди сообщений, сначала решить, в состоянии ли они зафиксировать транзакцию, и только после того, как все участвующие в распределенной транзакции менеджеры ресурсов соглашаются произвести фиксацию, TPM запрашивает у них выполнение фиксации.

Вызовы удаленных процедур и транзакции представляют собой полезные абстракции в тех случаях, когда взаимодействие между компонентами распределенной системы является принципиально синхронным. Однако имеются ситуации, когда более уместен асинхронный стиль взаимодействия. Например, если компоненты распределенной системы функционируют в разных часовых поясах, и их доступность не гарантируется, может оказаться предпочтительным их буферизуемое взаимодействие. Аналогично, в архитектурах, поддерживающих требования высокой пропускной способности, часто требуется буферизация запросов для обеспечения постоянного коэффициента загруженности процессоров. Такие асинхронные взаимодействия сегодня главным образом реализуются с использованием абстракции передачи сообщений, которая поддерживается промежуточным программным обеспечением, ориентированным на сообщения (message oriented middleware, MOM). MOM поддерживает очереди сообщений (message queue), через которые компоненты распределенной системы могут обмениваться сообщениями асинхронным и надежным образом. В очередях сообщений сообщения могут сохраняться персистентно, так что они могут пережить сбои промежуточного программного обеспечения и получателя. В очередях сообщений обычно поддерживаются двухточечные коммуникации и коммуникации на основе «публикации/подписки». В очередях сообщений также поддерживаются распределенные транзакции, так что сообщения могут ставиться в очередь и изыматься из очереди под транзакционным управлением.

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

Назад Содержание Вперёд