Такая поддержка увеличивает эффективность распределенного объектного промежуточного ПО как платформы для систем реального времени, для которых критически важное значение имеет производительность

Постоянно растущий класс систем реального времени требует сквозной поддержки различных аспектов качества обслуживания (QoS — Quality of Service), в том числе полосы пропускания, параметров задержки, уровня искажения сигнала и надежности. Эти системы используются для контроля [1], управления производственными процессами, видеоконференций, крупномасштабных распределенных интерактивных моделей и получения данных с радиолокаторов. Такие системы требуют гарантированного обеспечения качества обслуживания. Более того, они все шире применяются в компаниях, работающих на рынках, где отмена государственного регулирования, высокая конкуренция на международном уровне и бюджетные ограничения требуют от программного обеспечения повышенной производительности и качества.

В поиске решения этой задачи разработчики обращаются к распределенному объектному промежуточному программному обеспечению, такому как Common Object Request Broker Architecture - отраслевому стандарту, принятому консорциумом Object Management Group (OMG) [2]. В сложных системах реального времени промежуточное ПО размещается между приложениями и базовыми операционными системами, стеками протоколов и аппаратным обеспечением. CORBA помогает снизить временные и производственные затраты на разработку систем за счет объединения приложений, состоящих из многократно используемых программных компонентных служб, вместо того чтобы полностью создавать их «с нуля». Спецификация Real-Time CORBA включает в себя функции управления ресурсами процессора, сети и памяти [3]. Данная статья описывает основные возможности Real-Time CORBA, представляющие первостепенное значение для исследователей и разработчиков встроенных программ и распределенных систем реального времени.

Общее описание Real-Time CORBA

Спецификация Real-Time CORBA 1.0 определяет стандартные функции, которые позволяют точно предсказать поведение операций в приложениях CORBA с фиксированными приоритетами (где операции выполняются в предварительно определенном приоритетном порядке). Данная спецификация расширяет существующий стандарт CORBA и недавно принятую спецификацию OMG Messaging [4]. В частности, RT-CORBA 1.0 использует функции General Inter-ORB Protocol/Internet Inter-ORB Protocol (GIOP/ IIOP) версии 1.1 и наборы правил обеспечения качества обслуживания, описанные в спецификации OMG CORBA Messaging. Новый стандарт CORBA 3.0 будет интегрировать в себе все эти функции и спецификации.

Рис. 1. Роли брокера объектных запросов и конечных систем при вызове объектных методов для Real-Time CORBA. Клиент получает ссылку на объект и выполняет вызов метода на объекте. «Заглушка» клиента предлагает средство преобразования вызова в запрос ORB. Этот запрос передается на сервер, который может быть другой конечной системой, нежели клиент. ORB предлагает службы низкого уровня, поэтому данный вызов метода может быть прозрачно передан на корректную конечную систему. На сервере ORB передает запрос адаптеру мобильных объектов, который определяет местонахождение объекта и метода и выполняет вызов (up call). Все выходные параметры возвращаются клиенту. Брокер объектных запросов может поддерживать более одной конечной системы (как показано зигзагообразной линией)

Как показано на рис. 1, с точки зрения CORBA конечная система брокера объектных запросов (другими словами, узел в сети) состоит из сетевых интерфейсов, подсистем ввода/вывода операционной системы, коммуникационных протоколов, а также служб и компонентов промежуточного программного обеспечения, соответствующего стандарту CORBA [5]. Спецификация RT-CORBA определяет возможности, которые конечные системы ORB должны интегрировать и управлять ими вертикально (от сетевого интерфейса до уровня приложений) и горизонтально (в рамках всей сети), чтобы гарантировать предсказуемость поведения всех операций и на всем пути между серверами и клиентами CORBA. В следующих разделах приводится список возможностей от самого нижнего абстрактного уровня и до высокоуровневых служб и приложений.

Управление ресурсами коммуникационной инфраструктуры

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

Механизмы планирования ОС

Брокеры объектных запросов используют механизмы операционной системы для сквозного планирования операций на уровне приложений. Поскольку спецификация RT-CORBA 1.0 ориентирована на системы реального времени с фиксированными приоритетами, эти механизмы соответствуют управлению приоритетами планирования нитей в операционных системах. RT-CORBA в первую очередь рассчитана на операционные системы, которые позволяют приложениям указывать приоритеты и правила планирования. Например, расширения реального времени в IEEE Posix 1003.1c определяют правило планирования со статичными приоритетами по принципу «первый пришел - первый ушел» (FIFO), которое удовлетворяет этим требованиям.

Конечная система ORB реального времени

Брокеры объектных запросов передают запросы между клиентами и серверами прозрачным образом. Конечные системы ORB реального времени должны предлагать стандартные интерфейсы так, чтобы приложения могли передать ORB свои требования к ресурсам. Набор правил, определенный спецификацией CORBA Messaging, позволяет приложениям конфигурировать ресурсы конечных систем ORB, такие как приоритеты нитей, буферы для очередей сообщений, соединения транспортного уровня и передачу сигналов, для управления поведением ORB.

Службы и приложения реального времени

Наличие управляемых конечных систем ORB реального времени и коммуникационных ресурсов - всего лишь часть решения. Кроме того, RT-CORBA ORB должны поддерживать эффективное, масштабируемое и предсказуемое — из конца в конец — поведение для компонентов высокоуровневых служб и приложений. К примеру, глобальная служба планирования может управлять и планировать резервирование распределенных ресурсов [5, 6]. Эта служба может взаимодействовать с ORB, чтобы предоставить механизмы, которые поддерживают определенные и обязательные сквозные временные характеристики выполнения операций. Разработчики приложений могут затем создать свои программы так, чтобы они использовали функции, экспортированные брокером объектных запросов реального времени и связанных с ним высокоуровневых служб.

Стандартные интерфейсы и правила

Чтобы управлять этими возможностями, RT-CORBA определяет стандартные интерфейсы и правила QoS, которые позволяют приложениями конфигурировать и управлять:

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

Обычно наряду с другими правилами приложения указывают эти правила поддержки качества обслуживания в реальном времени при вызове стандартных операций ORB, таких как create_POA() или validate_connection(). К примеру, адаптер мобильных объектов (portable object adapter, POA), поддерживающий QoS, используется для создания ссылки на объект и гарантирует, что любое серверное правило, которое затрагивает клиентские запросы, встраивается в адресуемый компонент объекта, на который указывает ссылка. Адресуемые компоненты - это пары «имя - значение», используемые для экспорта атрибутов (таких как значения уровня защиты или QoS) с сервера на его клиенты внутри ссылок на объекты. Таким образом, клиенты, которые вызывают операции на таких ссылках, могут соблюдать правила, требуемые адресуемым объектом.

Рис. 1 показывает, как различные функции RT-CORBA соотносятся с существующим стандартом CORBA.

Управление процессорными ресурсами

Строгий контроль за планированием и использование процессорных ресурсов имеют критически важное значение для многих приложений реального времени с фиксированными приоритетами. В силу чего, спецификация RT-CORBA позволяет клиентским и серверным приложениям:

  • определять приоритет, с которым будут обрабатываться вызовы CORBA;
  • ограничивать приоритеты нитей ORB и гарантировать, что внутрипроцессная синхронизация нитей выполняется согласованно, не меняя порядка приоритетов [7].

Кроме того, RT-CORBA позволяет серверам предопределять пулы нитей.

Механизм поддержки приоритетов в RT-CORBA не может творить чудеса. Промежуточное программное обеспечение ORB не может по мановению волшебной палочки обеспечить полностью детерминированное поведение операционной системы или коммуникационной инфраструктуры, которые не работают в реальном масштабе времени. Но в подходящей среде определенные функции RT-CORBA могут помочь разработчикам и интеграторам приложений сконфигурировать гетерогенные среды, способные поддерживать приоритеты в рамках системы в целом.

Механизмы поддержки приоритетов

Традиционные брокеры объектных запросов CORBA не дают клиентам стандартных средств сообщить ORB относительные приоритеты своих запросов. Однако эта возможность крайне необходима для минимизации изменения порядка приоритетов, а также для ограничения длительности задержки и уровня искажений при работе приложений с определенными требованиями к качеству обслуживания в реальном времени. С этой целью спецификация RT-CORBA определяет независящие от платформы механизмы управления приоритетами при вызове операций.

Система типов приоритетов. Спецификация RT-CORBA определяет два типа приоритетов (CORBA и внутренний) для поддержки гетерогенности операционной системы. Каждая одно- или двусторонняя операция CORBA получает приоритет CORBA от 0 до 32767. Каждая конечная система ORB, расположенная вдоль активного пути, может отображать приоритеты CORBA на внутренние приоритеты - приоритеты, уникальные для конкретной конечной системы.

Модели приоритетов. Спецификация RT-CORBA определяет правила PriorityModel, как показано на Рис. 2, с помощью двух значений: декларированного на сервере и распространяемого на клиенте.

Рис. 2. Модели приоритетов в Real-Time CORBA: (a) сервер декларирует, и (b) клиент распространяет

С помощью приоритетов, декларированных на сервере, сервер определяет приоритет, с которым будет выполняться вызов конкретного объекта. Сервер, основываясь на значении правила PriorityModel в POA, где был активирован объект, устанавливает приоритет априори. Данный приоритет кодируется как адресуемый компонент в объекте, на который указывает ссылка, а затем публикуется на клиенте, как показано на рис. 2a.

Хотя сервер декларирует приоритет, клиентский ORB знает о выбранном правиле модели приоритетов и может использовать эту информацию внутри. К примеру, ORB может дополнительно использовать соответствующие приоритеты вызовов и диапазонов приоритетов с приоритетами, объявленными сервером для реализации соединений с выделенными приоритетами (priority-banded). Таким образом, ORB может гарантировать, что вызовы клиентов для конкретного объекта возникают на сервере с назначенным приоритетом.

Декларируемая сервером модель, хотя она полезна для определенных приложений реального времени, для всех случаев не подходит. К примеру, сервер может избежать инверсии приоритетов, обрабатывая входящие запросы с приоритетом, эквивалентным той нити клиента, которая первоначально инициировала операцию [7]. Модель RT-CORBA, предусматривающая распространение приоритетов клиентами, позволяет клиентам определять приоритеты вызовов, которым должны следовать серверы. При такой модели каждый вызов передает CORBA-приоритет операции в списке контекста службы, который транслируется вместе с ее запросом GIOP. Каждая конечная система вдоль активного пути между клиентом и сервером отображает свой сквозной приоритет CORBA на приоритет, поддерживаемый операционной системой. Затем конечная система обрабатывает запрос с этим внутренним приоритетом. Более того, если клиент вызывает двустороннюю операцию, его приоритет CORBA определяет приоритет ответа.

На рис. 2b клиент конечной системы A брокера объектных запросов вызывает сервер на конечной системе C. Затем конечная система C вызывает промежуточную конечную систему B. Каждая конечная система ORB работает с операционными системами в различных диапазонах внутренних приоритетов цепочек. Приоритет CORBA клиента распространяется с запросом. Каждый промежуточный сервер вдоль активного пути отображает приоритет CORBA клиента на внутренний приоритет, соответствующий его хост-платформе и сквозному глобальному приоритету. Например, в Windows NT глобальный приоритет CORBA может соответствовать 26 внутреннему приоритету операционной системы. В Solaris тот же самый глобальный приоритет CORBA может соответствовать нити реального времени с приоритетом 135.

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

В силу вышесказанного, спецификация RT-CORBA позволяет серверному приложению определить преобразование приоритетов, которое устанавливает приоритет для выполнения конкретных вызовов. Приоритет может зависеть от внешних факторов, таких как текущий уровень нагрузки на сервере, важности операции [5] или состояния глобальной службы планирования [6]. Сервер реализует преобразования в виде специальных программ (hook), которые он применяет, когда получает или отсылает запросы. Программа преобразования получает текущий приоритет CORBA и идентификатор адресуемого объекта и может изменить приоритет вызова, к примеру, запуская код, предлагаемый приложением.

Входящее преобразование возникает во время передачи вызова, то есть после получения его ядром ORB, но перед тем как обслуживающая операция отправлена на сервер. Исходящее преобразование, с другой стороны, возникает тогда, когда обслуживающая программа инициирует операцию передачи следующему промежуточному узлу. Эта операция возникает всякий раз, когда обслуживающая программа вызывает операцию на объекте.

Пулы нитей

Многие встроенные системы используют многопоточный режим для того чтобы различать разные типы служб, такие как задачи с высоким и низким приоритетом [1], и поддерживать выгрузку нитей для предотвращения переупорядочивания приоритетов. До спецификации RT-CORBA, однако, отсутствовал стандартный программный интерфейс для программирования многопоточных серверов CORBA. Из-за чего разработчики не могли использовать CORBA для программирования многопоточных систем реального времени, не прибегая к собственным функциям ORB.

Модель взаимно-согласованной параллельной обработки (reactive concurrency model) - единственный способ реализовать серверный брокер объектных запросов без нитей [8]. Серверный ORB читает каждый запрос от базового коммуникационного механизма, обрабатывает его для выполнения, затем извлекает следующий запрос и так далее. Если все запросы требуют фиксированной, относительно небольшой обработки, то оказывается приемлемоймодель взаимно-согласованной одновременной обработки. Однако многие распределенные приложения обладают сложными объектными реализациями, которые требуют различного по времени (а иногда и длительного) выполнения. Более того, чтобы избежать неограниченной инверсии приоритетов и блокировки, приложения реального времени часто требуют использования некоторой упреждающей многопоточности.

RT-CORBA решает проблемы параллельной обработки с помощью стандартной модели пула нитей [8]. Эта модель позволяет разработчикам серверов заранее резервировать пулы нитей и присваивать необходимые значения определенным атрибутам нитей, таким как уровни приоритетов по умолчанию. Пулы нитей могут найти применение в конечных системах ORB реального времени и приложениях, создатели которых хотели бы использовать возможности многопоточной обработки, но располагают ограниченным объемом ресурсов памяти. Более того, разработчики могут оптимально конфигурировать пулы нитей в зависимости от того, поддерживается или не поддерживается буферизация запросов, обеспечивая тем самым более широкие возможности управления использованием памяти.

Разработчики могут определять и назначать пулы нитей для POA на сервере RT-CORBA. Каждый POA должен иметь один пул нитей, хотя пул нитей может обрабатывать запросы от нескольких POA. Спецификация RT-CORBA определяет два вида организации пулов нитей - с сегментацией и без сегментации.

Пулы нитей без сегментации. Простейшая модель организации пулов нитей RT-CORBA позволяет разработчикам управлять общим уровнем одновременной обработки в серверных брокерах объектных запросов и в приложениях. ORB обрабатывает сообщения от клиента, используя пул, имеющий фиксированное число статически зарезервированных нитей. Однако даже когда эти предварительно зарезервированные нити не используются, они все равно расходуют системные ресурсы. Интерфейс RT-CORBA дает разработчикам серверов возможность заранее резервировать минимальное, начальное число так называемых статических нитей, но этот пул может наращиваться динамически для обработки резко возросшего числа клиентских запросов.

Серверные приложения посредством системного вызова create_thread-pool() могут указать:

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

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

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

Пулы нитей с сегментацией. Во многих случаях использования встроенных систем реального времени пулам нитей статически назначаются глобальные приоритеты CORBA. К примеру, телекоммуникационное приложение может выбрать три различных приоритета, указывающих классы запросов с низкой задержкой, высокой пропускной способностью и наилучшим возможным обслуживанием соответственно. С другой стороны, фиксированный набор «скоростей» с соответствующими глобальными приоритетами CORBA хорошо подходит для приложений, предусматривающих периодическую обработку в реальном времени. В этих случаях необходимо распределять нити в пулах между подмножествами с различными приоритетами. Для этого RT-CORBA определяет модель пула нитей с сегментацией, благодаря которой разработчики могут указывать как максимальный объем общей одновременной обработки на сервере, так и работы, выполняемой с данным уровнем приоритета.

Для каждого сегмента в этой модели пула нитей сервер указывает приоритет CORBA, счетчик статических нитей и счетчик динамических нитей. Сервер присваивает динамическим нитям приоритет сегмента. Разработчики могут сконфигурировать пулы таким образом, чтобы сегменты с более высокими приоритетами заимствовали нити из сегментов с более низкими приоритетами. Приоритет позаимствованной нити временно повышается до приоритета позаимствовавшего ее сегмента. По завершении обработки вызовов нить возвращается в исходный сегмент, и ее приоритет устанавливается в предыдущее значение. Пулы нитей с сегментацией могут также поддерживать буферизацию запросов, если для обработки входящих запросов не доступна ни одна из нитей.

Стандартные синхронизаторы

Исходная спецификация CORBA не содержит определения модели обработки нитей. Приложения CORBA, таким образом, не имеют стандартного, переносимого API-интерфейса, который мог бы гарантировать согласованность между их механизмами синхронизации и внутренними механизмами синхронизации, используемыми брокером объектных запросов. Приложения реального времени, однако, требуют такой согласованности, чтобы поддерживать протоколы наследуемости приоритетов и определения максимального приоритета [7]. Спецификация RT-CORBA определяет стандартный набор взаимных исключений по местонахождению.

Глобальная служба планирования

Абстракции планирования, определенные в операционных системах реального времени, таких как VxWorks, LynxOS, и в реализациях Posix 1003.1c, являются достаточно низкоуровневыми. Например, эти абстракции требуют, чтобы разработчики устанавливали соответствие между требованиями к качеству обслуживания своих высокоуровневых приложений и низкоуровневыми механизмами операционной системы, такими как приоритеты нитей, а также параметры полосы пропускания и задержки виртуальных сетевых сегментов. Эти процедуры установки соответствия не кажутся интуитивным многим разработчикам, которые предпочитают работать на уровне интерфейсов объектов и объектных операций.

RT-CORBA определяет глобальную службу планирования таким образом, что приложения могут указывать требования к планированию на более высоком и понятном уровне [3]. Эта служба - объект CORBA, резервирует системные ресурсы так, чтобы обеспечить качество обслуживания, требуемое приложениям, которые совместно используют конечную систему ORB. Приложения могут использовать эту службу, указывая требования к обработке своих операций с помощью различных параметров, таких как максимально допустимое время или период исполнения.

Управляемые взаимодействия между ORB

Исторически сложилось так, что спецификация CORBA и традиционные брокеры объектных запросов обеспечивают прозрачность «местонахождения», которая позволяет приложениям не заботиться о том, находятся ли компоненты в разных или в одном и том же процессе. Более того, функции нижележащей операционной системы, сети и шины воспринимаются как черный ящик. Хотя подобная инкапсуляция полезна для приложений, которые требуют максимально возможного качества обслуживания, она не адекватна для систем, выдвигающих более жесткие требования к QoS.

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

Выбор и конфигурация свойств протоколов

CORBA использует механизмы внутренних коммуникаций ORB для обмена запросами между клиентами и серверами. Эти механизмы создаются на основе более низкоуровневых протоколов, которые обеспечивают различные виды механизмов QoS. Экземпляры Inter-ORB protocol (IOP) содержат и протокол ORB, и его отображение на конкретный базовый транспортный протокол. Например, IIOP отображает GIOP на протокол TCP/IP. Таким образом, IOP содержит два уровня протоколов - ORB и транспортный, каждый из которых имеет свой собственный набор свойств протокола.

RT-CORBA определяет интерфейс таким образом, что приложения могут указать свойства протокола ORB или транспортного протокола, которые управляют различными функциями коммуникационного протокола, такими как виртуальные сегменты ATM или спецификация трафика протокола RSVP. Структура данных Protocol определяет каждый набор свойств протокола ORB или транспортного протокола, как показано в следующем определении на языке CORBA Interface Definition Language (IDL).

interface ProtocolProperties {};
typedef struct {
	IOP::ProfileId protocol_type;
	ProtocolProperties
		orb_protocol_properties;
	ProtocolProperties
		transport_protocol_
properties;
} Protocol;
typedef sequence 
	ProtocolList;

Порядок, в котором свойства протокола перечисляются в списке ProtocolList, показывает приоритетность протокола. К примеру, клиент может указать, что IIOP имеет предпочтение перед другой комбинацией протоколов. Чтобы приложения могли выбирать и конфигурировать требуемые им свойства протокола ORB или транспортного протокола, RT-CORBA определяет правила ClientProtocol и Server-Protocol QoS.

Свойства серверных протоколов. Серверы CORBA могут использовать правила ServerProtocol для того чтобы выбрать протоколы для конфигурации в ссылке на объект. Это правило может быть пропущено другими правилами POA при вызове операции create_POA() на интерфейсе Portable-Server: :POA. Правило ServerProtocol имеет два назначения:

  • публикация списка допустимых для клиента протоколов;
  • определение атрибутов конфигурации протокола для серверных соединений.

POA гарантирует, что порядок профайлов в ссылках на объекты соответствует порядку протоколов, указанных в правиле ServerProtocol. В силу этого сервер может сообщать клиентам о том, какие протоколы для него предпочтительнее, передавая им ссылки на объекты, чьи профайлы перечислены в определенном порядке. Когда клиент получает ссылку на объект, он может либо принять предпочтения сервера, либо использовать другие критерии выбора.

Свойства клиентских протоколов. Клиентские приложения могут использовать правило ClientProtocol для того, чтобы выбрать, какие протоколы использовать при связи с объектами. Это правило вступает в силу, когда клиент получает связь с объектом. Правило ClientProtocol показывает свойства протокола, в которых заинтересован клиент, а также порядок его предпочтений.

Либо клиент, либо сервер, но не оба одновременно для одной и той же ссылки на объект, могут устанавливать правило ClientProtocol. Серверы могут публиковать конкретные требования к протоколам и предпочтения для каждого объекта в отдельности; клиенты могут менять правила протоколов при каждом вызове. Если сервер определил правило ClientProtocol, он передает это правило клиенту в ссылке на объект. На рис. 3 показано, как сервер может назначать протоколы, доступные для клиентов. Эта функция позволяет серверу указывать конкретные требования к протоколам ORB на клиентах.

Рис. 3. Конфигурация и выбор свойств протоколов. Сервер назначает протоколы, доступные для клиента (стеки показывают одну ссылку на объект с несколькими адресами, специфичными для протоколов). Сервер публикует протоколы среды виртуальной машины (VME — Virtual Machine Environment), ATM или TCP в адресуемом компоненте в ссылке на объект. Затем клиент должен следовать правилу ClientProtocol, переданному сервером, и выбрать один из этих трех протоколов. (Белая зигзагообразная линия указывает на один или несколько хостов)

Наследование интерфейса может определять конкретные свойства для конкретных протоколов. Например, стандартные свойства TCP - следующие:

interface TCPProtocolProperties
	: ProtocolProperties
{
	attribute long send_buffer_size;
	attribute long recv_buffer_size;
	attribute boolean keep_alive;
	ttribute boolean dont_route;
	ttribute boolean no_delay;
};

Этот интерфейс свойств протокола позволяет приложениям устанавливать общие атрибуты TCP конечных точек. Например, атрибуты размера буферов получения и передачи могут определять размер очередей соединения конечных точек. Многие реализации TCP используют эти значения для того чтобы определить размер окна TCP, который, в свою очередь, влияет на сквозную полосу пропускания. Если установлен атрибут keep_alive, тогда TCP будет тестировать интерактивные соединения с тем, чтобы убедиться в их корректности. Наконец, атрибут no_delay отключает алгоритм Nagle в TCP (функцию TCP, которая пытается минимизировать число небольших пакетов в сети, тем самым снижая нагрузку) так, что небольшие запросы могут быть посланы даже если более ранние запросы еще не подтверждены.

Явное связывание

Исходная спецификация CORBA поддерживала только неявное связывание (implicit binding) [2]. Эта модель предоставляет ресурсы по требованию (например, после первого обращения клиента к серверу) вместе с путем обмена между клиентом и его серверным объектом.

К сожалению, неявное связывание не подходит для приложений реального времени со строгими требованиями к качеству обслуживания. В частности, отложенная активация связи объект - сервер и резервирование ресурсов до времени исполнения могут значительно увеличить задержку и уровень искажений. Более того, из-за блокировки по началу очереди (head-of-line blocking), связанной с тем, что очереди соединений обрабатываются в порядке «первый пришел - первый ушел», мультиплексирование соединений может вызвать значительную инверсию приоритетов [8].

Чтобы избежать таких проблем, RT-CORBA предоставляет механизм явного связывания (explicit binding), который использует операцию validate_connection, определенную в интерфейсе CORBA::Object в спецификации CORBA Messaging. Этот механизм позволяет клиентам предварительно устанавливать соединения с серверами и управлять тем, как клиентские запросы передаются по этим соединениям.

Соединения с выделенными приоритетами (priority-banded connection). Эти соединения позволяют клиентам указывать точные приоритеты для каждого сетевого соединения. Кроме того, клиенты могут выбирать подходящие соединения во время исполнения с учетом приоритета, который CORBA присваивает той нити, вызвавшей операцию. Когда клиенты устанавливают гарантированные соединения, они должны указать правила, определяющие один или несколько диапазонов приоритетов.

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

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

Частные соединения. Многие брокеры объектных запросов поддерживает мультиплексированные соединения, использующие ограниченные ресурсы операционной системы более эффективно, чем традиционные, немультиплексированные соединения (где каждый вызов может потребовать нового клиент-серверного соединения) [8]. Однако приложения реального времени часто требуют выделенных (немультиплексированных) соединений, которые хорошо подходят для приложений с четко определенными требованиями качества обслуживания. В этом случае, соединение не может быть повторно использовано для другого двунаправленного запроса до тех пор, пока не получен ответ на предыдущий запрос. Чтобы поддерживать эту возможность, RT-CORBA предоставляет PrivateConnection. Это правило позволяет клиентам выбрать выделенные соединения, которые минимизируют длительность любой сквозной инверсии приоритетов. Как ни странно, RT-CORBA не имеет API-интерфейса, необходимого для того чтобы гарантировано затребовать мультиплексированное соединение, используя эту функцию вместо того, чтобы вдаваться в детали реализации ORB.

Рис. 4. Явное связывание. Вызовы передаются от клиента к серверу через предварительно зарезервированное соединение (волнистые линии представляют нити) в фиксированном диапазоне приоритетов (например, P1-5 означает величины приоритетов от 1 до 5)

На рис. 4 показано использование между клиентом и сервером соединений с выделенными приоритетами. Выделенные соединения имеют приписанные диапазоны приоритетов, в силу чего, каждая клиентская операция передается на сервер через предварительно зарезервированное соединения, которое назначается для каждого фиксированного диапазона приоритетов. (Соединение может быть связано с одним приоритетом или с целым диапазоном приоритетов. Например, все вызовы с приоритетами от 20 до 30 используют соединение X). Серверный брокер объектных запросов обрабатывает запрос на обслуживание с конкретным приоритетом и посылает ответ по тому же самому немультиплексированному соединению. Эта комбинация функций поддерживает сквозную систему приоритетов и сокращает число основных источников переупорядочивания приоритетов.

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

Чтобы распределенные приложения следующего поколения могли удовлетворить требования QoS, необходима интегрированная архитектура, которая способна обеспечить сквозную поддержку качества обслуживания на различных уровнях. Распределенное объектное промежуточное программное обеспечение, базирующееся на RT-CORBA 1.0, предлагает решения части вопросов, связанных с управлениями ресурсами, с которыми сталкиваются исследователи и разработчики систем реального времени [3], в частности для систем, способных использовать планирование фиксированных приоритетов.

Однако определенный класс критически важных приложений не может удовлетворить требования гарантированного качества обслуживания в условиях динамически меняющейся нагрузки, используя только функции, стандартизованные в спецификации RT-CORBA 1.0 [6]. Более того, разработчики сложных, критически важных приложений придут к выводу, что априори очень трудно определить приоритеты различных операций, если только в системе нет избытка ресурсов. Чтобы решить эту задачу, OMG стандартизует методики динамического планирования, такие как планирование на основе конкретных сроков [9] или значений параметров.

Свободно распространяемую, с открытыми исходными текстами реализацию RT-CORBA, получившую название TAO (The ACE ORB — адаптивная коммуникационная среда ORB) можно найти в Web по адресу http://www.cs.wustl.edu/~schmidt/TAO.html. TAO используется в самых разных встроенных системах реального времени, в том числе в архитектуре электронных систем управления полетом корпорации Boeing [1], предлагаемой Science Applications International (реализации Run Time Infrastructure следующего поколения для High Level Architecture агентства Defense Modeling and Simulation Organization, а также для экспериментов в области физики высоких энергий в центре Stanford Linear Accelerator Center и в обсерватории Keck Observatory на Гавайских островах.

Благодарности

В этой работе мы получили поддержку компаний Boeing, BBN, Cisco, агентства ARPA Министерства обороны США по контракту Contract 9701516, NSF Grant NCR-9628218, а также Motorola, Siemens и Sprint.

Об авторе

Дуглас Шмидт - адьюнкт-профессор Калифорнийского университета. Он занимается вопросами объектно-ориентированных методов создания высокопроизводительных распределенных объектных вычислительных систем реального времени на платформах параллельной обработки, работающих на высокоскоростных сетях ATM и межсоединениях встроенных систем. С ним можно связаться по адресу schmidt@uci.edu.

Фред Кунс - ведущий научный сотрудник факультета информатики Университета Вашингтона. К области его основных интересов относятся операционные системы и сетевая поддержка высокопроизводительных распределенных объектных вычислительных систем реального времени. С ним можно связаться по адресу fredk@cs.wustl.edu.

Литература

[1] T.H. Harrison, D.L. Levine, and D.C. Schmidt, «The Design and Performance of a Real-Time CORBA Event Service,» Proc. 1997 ACM SIGPLAN Conf. Object-Oriented Programming Systems, Languages, and Applications (OOPSLA 97), ACM Press, New York, 1997, pp. 184-200

[2] Object Management Group, The Common Object Request Broker: Architecture and Specification, 2.3 ed., June 1999

[3] Object Management Group, Realtime CORBA Joint Revised Submission, OMG document, ORBOS/99-02-12 ed., Mar. 1999

[4] Object Management Group, CORBA Messaging Specification, OMG document, ORBOS/98-05-05 ed., May 1998

[5] D.C. Schmidt, D.L. Levine, and S. Mungee, «The Design and Performance of Real-Time Object Request Brokers,» Computer Comm., Apr. 1998, pp. 294-324

[6] C.D. Gill, D.L. Levine, and D.C. Schmidt, «The Design and Performance of a Real-Time CORBA Scheduling Service,» to be published in Int?l J. Time-Critical Computing Systems, 2000

[7] R. Rajkumar, L. Sha, and J.P. Lehoczky, «Real-Time Synchronization Protocols for Multiprocessors,» Proc. 9th IEEE Real-Time Systems Symp., IEEE CS Press, Los Alamitos, Calif., 1988, pp. 259-269

[8] D.C. Schmidt et al., «Software Architectures for Reducing Priority Inversion and Non-Determinism in Real-Time Object Request Brokers,» to be published in J. Real-Time Systems, 2000

[9] Y.-C. Wang and K.-J. Lin, «Implementing a General Real-Time Scheduling Framework in the RED-Linux Real-Time Kernel,» Proc. 20th IEEE Real-Time Systems Symp., IEEE CS Press, Los Alamitos, Calif., 1999, pp. 246-255

An Overview of the Real-Time CORBA Specification, Douglas C. Schmidt, Fred Kuhns, IEEE Computer, June 2000, pp. 56-63, Reprinted with permission, 2000, Copyright IEEE CS, All rights reserved.