Распределенной обработки информации

2.1. Распределенная обработка информации

на базе механизма удаленного вызова процедур

  Спецификация удаленного вызова процедур (remote procedure call – RPC) поддерживает синхронный режим коммуникаций между двумя прикладными модулями (клиентом и сервером). Для установки связи, передачи вызова и возврата результата клиентский и серверный процессы обращаются к специальным компонентам – клиентскому и серверному переходникам, или заглушкам (от англ. stub – заглушка, переходник). Эти stub-процедуры не реализуют никакой прикладной логики и предназначены только для организации взаимодействия удаленных (в общем случае) прикладных модулей. Каждая функция на сервере, которая может быть вызвана удаленным клиентом, должна иметь такой процесс.

 При вызове клиентом удаленной процедуры вначале выполняется локальный вызов процедуры, являющейся частью клиентского переходника. Локальный вызов вместе с параметрами передается клиентскому переходнику. При этом с помощью специального языка описания интерфейсов (Interface Definition Language – IDL) производится определение интерфейса процедуры, то есть описание параметров процедуры, передаваемых ей до выполнения RPC и возвращаемых после завершения RPC. Затем это описание транслируется и производится упаковка данных в формат сообщения – маршалинг (marshaling). Клиентский переходник вызывает локальную операционную систему, которая пересылает сообщение удаленной операционной системе сервера. Удаленная операционная система передает сообщение серверному переходнику, реализующему серверную часть вызова и состоящему из программ получения запроса от клиента, форматирования данных (демаршалинг), вызова реальной процедуры (реализованной на сервере) и возврата результатов клиенту. Клиент блокируется и ждет ответа, а на сервере запускается серверный переходник, преобразующий сообщение в параметры локальной процедуры. Сервер видит вызов как прямое обращение к его локальной процедуре с нужными параметрами, выполняет вызов и передает результаты серверному переходнику. Серверный переходник форматирует результаты работы процедуры в сообщение для клиента и вызывает локальную операционную систему сервера. Операционная система сервера пересылает сообщение операционной системе клиента. Клиент выводится из состояния ожидания, его операционная система принимает сообщение и направляет его клиентскому переходнику, который извлекает результаты из сообщения, передает их клиенту и возвращает клиенту управление.

  Принципиальная схема организации удаленного вызова процедур представлена на рис. 2.1.

      

      

      

Рис. 2.1. Принципиальная схема организации удаленного вызова

процедур

 

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

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

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

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

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

  Большинство систем MW категории RPC базируется на стандарте DCE RPC (DCE – Distributed Computing Environment – «среда распределенных вычислений») организации Open Group. Эти системы свободно распространяются в виде исходных кодов и существуют в реализациях ряда поставщиков ПО, которые настраивают этот код на определенную операционную систему. Помимо базового механизма взаимодействия распределенных приложений, в DCE реализованы некоторые важные для распределенной среды службы, такие как служба каталогов, средства защиты и распределенная файловая система.

 

2.2. Объектно-ориентированный подход

к организации распределенной обработки информации

 

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

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

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

  При выполнении клиентом «привязки» к распределенному объекту в адресное пространство клиента загружается реализация интерфейса объекта, называемая заместителем (proxy). Заместитель клиента аналогичен клиентскому переходнику в механизме RPC. Он выполняет маршалинг параметров в сообщения при обращении к методам, демаршалинг данных из ответных сообщений с результатами обращения к методам, передачу результатов клиенту. Сами же объекты находятся на сервере и предоставляют необходимые клиентской системе интерфейсы. Входящий запрос на обращение к методу сначала попадают в так называемый серверный каркас, или скелетон (skeleton), аналогичный серверному переходнику в RPC. Cерверный каркас преобразует входящий запрос в обращение к методу через интерфейс объекта, находящегося на сервере. Каркас также отвечает за маршалинг параметров в ответных сообщениях и их пересылку заместителю клиента. Если объект физически распределен по нескольким вычислительным машинам, то это скрывается от клиентов за интерфейсами объектов.

 

 

 

Рис. 2.2. Принципиальная схема организации механизма удаленных объектов

 

  Форма существования объектов в распределенных системах чаще всего соответствует объектам выбранного объектно-ориентированного языка программирования. Такие объекты представляют собой так называемые объекты времени компиляции. Использование этих объектов в распределенных системах обычно значительно упрощает создание распределенных приложений. Недостатком использования таких объектов является их зависимость от конкретного языка программирования. Альтернатива состоит в создании распределенных объектов непосредственно во время выполнения. При этом подходе распределенные приложения не зависят от конкретного языка программирования и они могут быть созданы из объектов, написанных на различных языках. При работе с такими объектами времени исполнения для превращения конкретной программной реализации в объект, методы которого будут доступны с удаленной вычислительной системы, используется адаптер объектов, служащий оболочкой этой реализации с целью придания ей реализации видимости объекта. Чтобы сделать оболочку как можно проще, объекты определяются исключительно в понятиях интерфейсов, которые они реализуют. Реализация интерфейса регистрируется в адаптере, который уже создает интерфейс для удаленных обращений. Адаптер также принимает приходящие обращения и создает для клиентов образ удаленного объекта.

  Объекты подразделяются на сохранные (persistent) и транзитные, или нерезидентные (transient). Сохранный объект не зависит от своего текущего сервера и продолжает существовать, даже не находясь постоянно в адресном пространстве серверного процесса. Сервер, управляющий таким объектом, может сохранить состояние объекта во вспомогательном запоминающем устройстве и прекратить свою работу, а затем после запуска снова прочитать состояние сохранного объекта из запоминающего устройства в свое адресное пространство и приступить к обработке обращений к объекту. Нерезидентный объект существует, пока им управляет сервер. Если сервер завершает работу, то такой объект прекращает существовать.

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

  Клиент, осуществив связь с объектом, может через заместителя объекта обратиться к методам объекта. Таким образом при объектно-ориентированном подходе к распределенной обработке информации реализуется механизм так называемого удаленного обращения к методам (Remote Method Invocation – RMI). RMI и RPC схожи в организации маршалинга и передачи параметров, описание интерфейсов объектов проводится на языке определения интерфейсов. Основное различие между RMI и RPC состоит в том, что RMI главным образом поддерживает внутрисистемные ссылки на объекты. В RMI отпадает необходимость в клиентских и серверных переходниках общего назначения. Вместо них используются значительно более удобные в работе и специфические для объектов средства – клиентский заместитель объекта и серверный каркас.

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

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

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

  На основе механизма RMI разработано множество стандартов и программных реализаций объектно-ориентированных платформ промежуточного ПО, поддерживающих эффективную распределенную обработку информации.

  Стандарт CORBA (Common Object Request Broker Architecture – «обобщенная архитектура брокера объектных запросов»), продвигаемый рабочей группой по управлению объектами консорциума OMG (Object Management Group), – это архитектура и спецификация для создания и управления объектно-ориентированными приложениями, распределенными в вычислительной сети. К настоящему время выработано несколько версий стандарта CORBA. Спецификацией не определяются ни языки программирования разрабатываемых объектно-ориентированных приложений, ни операционные системы, в которых они должны работать.

  Система, подчиняющаяся спецификации CORBA, состоит из трех основных частей: брокера объектных запросов ORB (Object Request Broker), набора служб (CORBAServices), доступных с помощью стандартизованного прикладного программного интерфейса, и набора средств и инструментов. ORB является основой каждого процесса на клиенте и на сервере в любой распределенной системе типа CORBA. Брокеры объектных запросов отвечают за поддержание связи между объектами и их клиентами, скрывая проблемы распределенности и разнородности системы. ORB содержит базовые функции взаимодействия объектов. Эти функции гарантируют обращение к серверу объектов и возвращение клиенту ответов сервера. Службы предоставляют функции сохранности, управления жизненным циклом, безопасности и многие другие. Принципиальная схема организации системы CORBA показана на рис. 2.3.

  Укрупненная последовательность действий брокера ORB при реализации вызова метода удаленного объекта состоит из следующих этапов:

  а) найти удаленный объект;

  б) активизировать модуль, содержащий искомый объект, если таковой еще не активизирован;

 в) передать аргументы удаленному объекту;

  г) ожидать ответа после вызова метода удаленного объекта;

  д) вернуть клиенту информацию или исключение, если вызов удаленного метода оказался неуспешным.

  Интерфейсы объектов описываются на языке описания интерфейсов IDL. В дополнение к описанию методов, в отличие от систем на базе RPC, язык IDL CORBA поддерживает множество объектно-ориентированных концепций, например, наследование и полиморфизм. Запись на IDL передается компилятору, который формирует заместитель объекта, скрывающий распределенность, и каркас (скелетон). Для клиента вызовы выглядят не удаленными, а локальными. Программа заместителя объекта содержит в себе описание методов, предоставляемых реализацией объекта, она загружается вместе с программой клиента. Каркас защищает сервер от проблем распределенности, поэтому сервер может разрабатываться так, как если бы вызовы к нему поступали из локального окружения. Все, что требуется знать программисту, это IDL-интерфейс сервера. Семантика интерфейсов методов не формализуется, она описывается другими средствами, например, в виде комментариев или в составе сопроводительной документации. Стандарт CORBA 3 поддерживает IDL для C, C++, Java, Smalltalk, Lisp, Ada и других языков.

 

 

Рис. 2.3. Принципиальная схема архитектуры системы CORBA

      

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

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

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

  Кратко представим основные службы CORBA.

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

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

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

  Служба событий (или служба уведомлений) рассылает уведомления о событиях в системе объектам системы. Уведомлением называется сообщение, которое объект посылает объектам для информирования о наступлении события. Поставщики поставляют события, а получатели обрабатывают их с помощью обработчиков. В push-модели активной стороной является поставщик событий, а получатели заранее регистрируются в канале событий для указания интереса к событиям данного типа. Получатель может отсоединиться от канала и прекратить прием событий. В pull-модели получатель сам запрашивает у поставщика данные о событии через обращение к методам канала, а регистрацию проходят поставщики. Получатель может организовать опрос объектов о наличии событий, а поставщики могут отсоединяться от канала, прекращая поступление к себе мешающих им запросов. Канал событий поддерживает обе модели, что позволяет множеству поставщиков взаимодействовать с множеством получателей асинхронно и без каких-либо дополнительных сведений друг о друге.

  Служба сохранности объектов обеспечивает механизм сохранения состояний объектов как в реляционных, так и в объектных базах данных. Для одноуровневых хранилищ (объектных СУБД) клиент не должен знать, где находится объект – в памяти или на диске. Объекты в двухуровневых хранилищах (реляционных СУБД) различаются по месту их размещения. Клиент может пользоваться возможностями автоматического управления сохранностью данных или управлять сохранностью самостоятельно. Служба не нарушает принцип инкапсуляции, но позволяет увидеть некоторые детали, то есть определить, когда объект сохранен, а когда – восстановлен.

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

  Служба объектных транзакций OTS (Object Transaction Service) взаимодействует непосредственно с самим брокером. Совместная задача брокера и OTS – автоматическое обеспечение единой среды для работы всех существенных компонентов системы. Подробнее вопросы транзакционного взаимодействия рассмотрены далее в разделе 2.3.

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

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

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

  Служба коллекций нужна для создания групп объектов и управления этими группами. Служба вводит несколько видов стандартных коллекций – множества, наборы, последовательности и другие. На их базе определены более сложные интерфейсы – очередь, двусторонняя очередь, очередь с приоритетом, стек, список, массив, дерево. Для каждого вида коллекции объектов определен свой интерфейс создания коллекции и свои средства организации перебора элементов коллекции. В коллекции можно добавлять элементы, менять их на другие элементы, извлекать элементы, удалять элементы из коллекций. Коллекции могут иметь свойства упорядоченности элементов, доступа по ключу, сравнимости и уникальности элементов.

  Служба запросов предназначена для поиска объектов, которые соответствуют заданным критериям, записываемым на расширенном последовательном языке запросов SQL (Sequential Query Language) либо на объектном языке запросов OQL (Object Query Language).

  В ряде случаев существуют проблемы совместимости, возникающие вследствие того, что построенные на основе спецификации CORBA распределенные системы разных производителей имеют собственные способы реализации взаимодействия между клиентами и серверами объектов (например, в некоторых системах клиент может обратиться к объекту на сервере только тогда, когда клиент и сервер используют один и тот же брокер ORB). Эти проблемы решаются путем введения стандартизованного протокола обмена между различными брокерами ORB в комбинации с универсальным способом создания ссылок на объекты. Такой протокол в CORBA известен как обобщенный протокол обмена между ORB (General Inter-ORB Protocol – GIOP). Конкретная реализация GIOP должна выполняться поверх существующего транспортного протокола. Реализация GIOP поверх транспортного протокола TCP (Transmission Control Protocol – протокол управления передачей) называется Интернет-протоколом обмена между ORB (Internet Inter-ORB Protocol – IIOP). Протокол GIOP (включая IIOP и его другие реализации) поддерживает несколько типов сообщений, в том числе два наиболее важных – Request и Replay, которые вместе образуют часть реализации удаленных обращений к методам.

  Компании, разрабатывающие ПО распределенных систем, используют спецификацию CORBA для создания собственных продуктов, которые могут взаимодействовать друг с другом по протоколу POP (Post Office Protocol – протокол почтового офиса). Спектр поддерживаемых служб для разных систем варьируется. К настоящему времени существуют десятки реализаций промежуточного ПО на основе CORBA.

Компанией Microsoft разработана компонентная объектная модель COM (Component Object Model) и ее версия DCOM (Distributed COM) для распределенных приложений. Модель DCOM (так же, как и CORBA) распространяет принципы удаленного вызова процедур на объектные распределенные приложения и обеспечивает прозрачность реализации и физического размещения серверного объекта для клиентской части приложения. Эта модель поддерживает возможность взаимодействия объектов, созданных на различных объектно-ориентированных языках и скрывает от приложения детали сетевого взаимодействия. В DCOM взаимодействие удаленных объектов базируется на спецификации DCE RPC. Ключевым компонентом DCE RPC является язык описания интерфейсов IDL, на уровне которого поддерживаются «контрактные» отношения между клиентом и сервером и обеспечивается независимость от конкретного объектно-ориентированного языка программирования. В модели DCOM также может использоваться язык IDL собственной разработки Microsoft MIDL (Microsoft IDL), который, однако, играет вспомогательную роль и используется в основном для удобства описания объектов. Как и в CORBA, объектная модель в DCOM построена на реализации интерфейсов. Один объект может реализовывать одновременно несколько интерфейсов. Однако (в отличие от CORBA) в DCOM имеются только бинарные интерфейсы. Бинарный интерфейс представляет собой таблицу с указателями на реализации методов, которые являются частью интерфейса. Достоинство бинарных интерфейсов состоит в том, что они не зависят от языка программирования. В отличие от модели CORBA, в которой для поддержки нового языка программирования необходимо каждый раз отображать описания IDL на конструкции этого языка, в DCOM подобная стандартизация не требуется.

  DCOM и CORBA, в отличие от процедурного RPC, дают возможность динамического связывания удаленных объектов (клиент может обратиться к серверу-объекту во время выполнения, не имея информации об этом объекте на этапе компиляции). Информацию о доступных объектах сервера на этапе выполнения клиентская часть программы получает из специального хранилища метаданных об объектах – репозитария интерфейсов (Interface Repositary) в модели CORBA и библиотеки типов (Туре Library) в модели DCOM. Эта возможность очень ценна для больших распределенных приложений, поскольку позволяет менять и расширять функциональность серверов, не внося существенных изменений в код клиентских компонентов программы, которых в корпоративной системе может быть множество. Например, в банковском приложении основная бизнес-логика поддерживается сервером в центральном офисе, а клиентские системы разбросаны по филиалам. Однако механизм динамического вызова CORBA относительно более сложен по реализации, чем в DCOM.

  Базовая реализация DСОМ интегрирована в Microsoft Windows. Для того, чтобы действительно активизировать объект, то есть гарантировать, что он создан и помещен в процесс, из которого будет в состоянии принимать обращения к методам, DСОМ использует реестр Windows в комбинации со специальным процессом – менеджером управления службами SCM (Service Control Manager). Кроме того реестр используется для записи отображения идентификаторов класса на локальные имена файлов, содержащих реализации классов. Чтобы создать объект, процесс сначала должен убедиться, что соответствующий объект класса загружен.

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

  Принципиальная схема архитектура системы DCOM представлена на рис. 2.4.

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

  Компания Microsoft внедряет DCOM и в другие операционные системы, например, Unix и OpenVMS. Однако CORBA изначально нацелена на кросс-платформенную поддержку (принцип «написано однажды, выполняется везде») и реализована для всех разновидностей Unix, всех версий Windows и многих других важных ОС, что имеет очевидное преимущество перед объектной моделью Microsoft. С другой стороны, Microsoft стремится интегрировать DCOM со средствами разработки приложений, чтобы максимально упростить создание клиент-серверных систем на базе этой технологии. Большинство популярных сред разработки, в том числе PowerBuilder, VisualC++, VisualBasic и Delphi имеют встроенную поддержку DCOM.

 

Рис. 2.4. Принципиальная схема архитектура системы DCOM

    

  Технологии интеграции распределенных объектов OMG и Microsoft пока достаточно четко разграничивают сферы влияния – CORBA успешно обслуживает большие гетерогенные системы, a DCOM используется в менее масштабных проектах на базе Windows. При этом во многих организациях стремятся объединить преимущества двух моделей, поэтому особую актуальность приобретают продукты, способные обеспечить взаимодействие объектов из разных объектных архитектур.

  Рассмотрим модель распределенных объектов Java.

  Язык Java поддерживает распределенные объекты исключительно в форме удаленных объектов (удаленный объект – это распределенный объект, тело которого постоянно находится на одной и той же машине, а интер­фейсы доступны удаленным процессам). Интерфейсы реализованы обычным об­разом через заместителя, который предоставляет те же интерфейсы, что и уда­ленный объект. Сам заместитель имеет вид локального объекта, находящегося в адресном пространстве клиента.

  Между удаленными и локальными объектами существует лишь несколько различий. Во-первых, значительно различается клонирование локальных и удаленных объектов. Клонирование локального объ­екта приводит к появлению нового объекта такого же типа и в точно таком же состоянии. Процедура клонирования возвращает точную копию клони­рованного объекта. Операция клонирования удаленного объекта производится только на сервере. Она приводит к созданию точной копии объекта в адресном пространст­ве сервера. Заместитель объекта не клонируется. Если клиент на удаленной ма­шине хочет получить доступ к клону объекта на сервере, он должен сначала вы­полнить повторную привязку к этому объекту. Более существенное различие между локальными и удаленными объектами в Java заключается в семантике блокировки объектов. Java позволяет построить любой объект в виде монитора. Для этого достаточно объявить один из методов синхронизируемым (synchronized). Если два процесса одновременно вызовут син­хронизируемый метод, работать будет только один из них, в то время как второй окажется заблокированным. Таким образом гарантируется, что дос­туп к внутренним данным объекта будет осуществляться только последовательно. Как и в мониторе, процесс может быть заблокирован и изнутри объекта в ожида­нии выполнения некоторого условия. Альтернативный подход состоит в том, чтобы производить блокировку толь­ко на сервере.

  Разработчики Java RMI ограничили блокировку удаленных объек­тов блокировкой заместителей.

  Поскольку разница между локальными и удаленными объектами на уровне язы­ка слабо заметна, Java может в ходе обращений к удаленным методам скрывать большую часть различий между ними. Так, в ходе обращения RMI в качестве па­раметра может быть передан любой простой или объектный тип, что предполага­ет возможность маршалинга типов. Единственное различие между локальными и удаленными объектами, наблю­даемое в процессе RMI, состоит в том, что локальные объекты передаются по значению (включая большие объекты, такие как массивы), в то время как удален­ные объекты передаются по ссылке. Другими словами, локальные объекты копи­руются, после чего копия используется в качестве параметра-значения. В случае удаленных объектов в качестве параметра используется ссылка на объект без копирования.

  При обращении RMI в Java ссылка на удаленный объект содержит сетевой адрес и конеч­ную точку сервера, а также локальный идентификатор необходимого объекта в адресном пространстве сервера. В ссылке на удаленный объ­ект, кроме того, кодируется стек протоколов, используемых клиентом и серве­ром для взаимодействия.

  Удаленный объект построен из двух различных классов. Один из классов содержит реализацию кода сервера и называется классом сервера. Класс сервера содержит реализацию той части удаленного объекта, которая выполня­ется на сервере. Другими словами, она содержит описание состояния (данных) объекта, а также реализацию методов обработки этого состояния. Из специфика­ции интерфейса объекта генерируется серверный переходник, то есть каркас (скелетон). Другой класс содержит реализацию кода клиента и называется классом клиен­та. Класс клиента содержит реализацию заместителя. Как и каркас, этот класс также автоматически создается из спецификации интерфейса объекта. В своей простейшей форме заместитель выполняет следующие действия – превращает каждый вызов метода в сообщение, пересылаемое реализации удаленного объекта, которая нахо­дится на сервере, а каждое ответное сообщение превращает в результат вызова метода. При каждом вызове он устанавливает связь с сервером, разрывая ее после завершения вызова. Для этого заместитель нуждается в сетевом адресе и конечной точке сервера.

  Таким образом, заместитель обладает всей информацией, необходимой для обращения клиента к методу удаленного объекта. В Java заместитель можно подвергнуть маршалингу и пере­слать в виде набора байтов другому процессу, в котором он может быть подвергнут обратной операции (демаршалингу) и использован для обращения к методам удаленного объекта. Косвенным результатом этого является тот факт, что замес­титель может быть использован в качестве ссылки на удаленный объект. Этот подход согласуется с методами интеграции локальных и распределен­ных приложений в Java. То есть заместитель можно передавать по сети как па­раметр RMI. В результате появляется возможность использовать заместитель как ссылку на удаленный объект.

  Такой подход к ссылкам на удаленные объекты отличается высокой гиб­костью и представляет собой одну из отличительных особенностей RMI в Java. В частности, это позволяет оптимизировать решение под конкретный объ­ект. Возможность передавать заместителя в виде параметра существует только в том случае, если все процессы работают под управлением одной и той же вир­туальной машины. Другими словами, каждый процесс работает в одной и той же среде исполнения. Переданный при маршалинге заместитель просто подвергает­ся демаршалингу на приемной стороне, после чего полученный код заместителя можно выполнять.

2.3. Реализация распределенной обработки информации

 на основе транзакционного взаимодействия

  Для реализации транзакционного взаимодействия применяются мониторы обработки транзакций TPM (Transaction Processing Monitor), или транзакционные мониторы, разработанные для обеспечения надежного мультиплексного доступа к большому количеству ресурсов для большого количества параллельных пользователей. Механизм TPM – наиболее старая технология реализации распределенных систем, которая появилась в 1970-х годах в среде больших универсальных вычислительных машин для выполнения банковских, страховых и других высококритичных вычислений.

  Транзакционные мониторы представляют одну из самых сложных и многофункциональных технологий в мире промежуточного ПО. Они предназначены для автоматизированной поддержки приложений, оформленных в виде последовательности транзакций. Каждая транзакция представляет собой законченный блок обращений к ресурсу (чаще всего – к базе данных) и некоторых действий над ним. Корректное выполнение транзакции должно гарантировать выполнение четырех условий – так называемых свойств ACID (Atomicity, Consistency, Isolation, Durability):

• Atomicity (атомарность)– операции транзакции образуют неразделимый, атомарный блок («unit of work» – «единица работы») с определенным началом и концом. Этот блок либо выполняется от начала до конца, либо не выполняется вообще. Если в процессе выполнения транзакции произошел сбой, происходит откат к исходному состоянию;

• Consistency (согласованность) – по завершении транзакции все задействованные ресурсы находятся в согласованном состоянии;

• Isolation (изолированность) – одновременный доступ транзакций различных приложений к разделяемым ресурсам координируется таким образом, чтобы эти транзакции не влияли друг на друга;

• Durability (долговременность) – все модификации ресурсов в процессе выполнения транзакции будут долговременными.

  В системе без TPM обеспечение свойств ACID берут на себя серверы распределенной базы данных на основе протокола 2РС – (two-Phase Commit – двухфазное подтверждение). Протокол 2РС описывает двухфазный процесс, в котором перед началом распределенной транзакции все системы опрашиваются о готовности выполнить необходимые действия. Если каждый из серверов баз данных дает утвердительный ответ, транзакция выполняется на всех задействованных источниках данных. Если хотя бы в одном месте происходит какой-либо сбой, будет выполнен откат всех частей транзакции.

  Однако в системе с распределенными базами данных выполнение протокола 2РС можно гарантировать только в том случае, если все источники данных принадлежат одному поставщику. Поэтому для сложной распределенной среды, которая обслуживает тысячи клиентских мест и работает с десятками разнородных источников данных, требуется использование механизма монитора обработки транзакций. Транзакционные мониторы способны координировать и управлять транзакциями, которые обращаются к серверам баз данных от различных поставщиков благодаря тому, что большинство этих продуктов помимо протокола 2РС поддерживают транзакционную архитектуру общего стандарта распределенной обработки транзакций DTP (Distributed Transaction Processing) для данной категории MW. Архитектура DTP поддерживает совместное использование ресурсов (файлов или баз данных) множеством программ, обеспечивая управление доступом, гарантирующее согласованность системы в целом.

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

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

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

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

  Полезность транзакционных мониторов и последующее появление брокеров объектов привело к построению объектно-ориентированных транзакционных мониторов или объектных мониторов транзакций ОТМ (object transaction monitor). Системы OTM берут лучшее из двух технологий. Они поддерживают объектную модель и при этом обеспечивают целостность распределенных транзакций на множестве разнородных источников данных, масштабируемость, надежность и высокую производительность – основные качества, присущие транзакционным мониторам. Кроме того, ORB сами по себе, как правило, не реализуют возможностей оптимального распределения нагрузки и восстановления при сбоях. Эти важнейшие службы высококритичной распределенной среды добавляются путем интеграции с технологией транзакционных мониторов. При этом ОТМ способны упростить развертывание транзакционных приложений. ТРM – одна из самых сложных в реализации категория MW, а строгая объектная архитектурная надстройка позволяет скрыть ее сложности от разработчика. Многие ОТМ также интегрируются с сервисами очередей сообщений (см. раздел 2.4), поддерживая тем самым асинхронную модель коммуникаций.

  Системы ОТМ отличаются от других средств интеграции разных категорий MW тем, что все необходимые свойства ТРM и ORB предоставляются в одном продукте. Многие представители категории ОТМ базируются на компонентной модели CORBA/Java (эти две технологии построения распределенных компонентных сред все более тесно интегрируются друг с другом) и стандартной транзакционной архитектуре DTP, поддерживая при необходимости работу с объектами DCOM. Так, консорциумом OMG была разработана спецификация объектного сервера транзакций OTS (Object Transaction Server), цель которой – унифицировать объединенную функциональность мониторов транзакций и брокеров объектных запросов. Это расширение CORBA нашло свое отражение в спецификации JTS для Java (Java Transaction Service– служба транзакций Java).

 

 

2.4. Распределенная обработка информации

на основе технологий обмена сообщениями

 

  Промежуточное ПО, ориентированное на обмен сообщениями (Message Oriented Middleware – MOM), относительно молодая и динамично развивающаяся категория систем промежуточного слоя. Согласно этой модели приложения обмениваются байтовыми строками – сообщениями, обращаясь к API-интерфейсу системы MOM, который изолирует их от непосредственного взаимодействия с ОС и сетевыми протоколами. В отличие от ранее рассмотренных моделей промежуточного ПО, MOM реализует скорее равноправные (peer-to-peer), чем подчиненные (клиент-сервер) отношения между модулями приложений. MOM можно считать и наиболее гибкой категорией MW, поскольку системы этого типа поддерживают как синхронные, так и асинхронные коммуникации на базе сетевых протоколов с установлением и без установления соединения. По способу обмена сообщениями все продукты MOM могут быть разделены на три подгруппы систем:

       1)с передачей сообщений,

  2)c очередями сообщений,

  3) типа публикация/подписка.

  Системы с передачей сообщений (Message Passing – MP) обеспечивают непосредственное взаимодействие приложений друг с другом путем отправки и получения сообщения. Для этого между программными модулями устанавливается логическое соединение. Отсюда следует, что данное решение не подходит для слабо связанных программ, работающих в независимом временном режиме, например, приложений, определенные компоненты которых обслуживают мобильных пользователей. Обмен сообщениями может происходить в синхронном и асинхронном режиме. Кроме средства непосредственных коммуникаций, системы этого типа могут обеспечивать дополнительные службы промежуточного слоя, например, службу каталогов.

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

  Большинство MQ-систем включает менеджер очереди (Queue Manager), который управляет локальными очередями, гарантирует передачу сообщений нужному адресату и, взаимодействуя с менеджерами на других узлах, следит за сетевым маршрутом передачи сообщения, выбирая альтернативный путь, если по тем или иным причинам основной оказывается недоступен.

  Принципиальная схема организации механизма очередей сообщений представлена на рис. 2.5.

 

      

Рис. 2.5. Принципиальная схема организации механизма

очередей сообщений

                

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

  Еще одной отличительной чертой промежуточных систем на основе очередей сообщений является обеспечение одного из трех уровней «качества обслуживания»:

  • надежная доставка сообщений (reliable message delivery) – система гарантирует, что в процессе обмена сообщениями ни один сетевой пакет не будет потерян;

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

  • застрахованная доставка сообщений (assured message delivery) – каждое сообщение доставляется только один раз.

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

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

  Представителями программных продуктов, построенных на базе очередей сообщений, являются системы MQSeries компании IBM, MSMQ (Microsoft Message Queuing Server) компании Microsoft, MessageQ компании BEA, dbQ компании Sybase.

  Еще одна модель обмена сообщениями – модель публикации/подписки (publlsh&subscribe) – имеет определенные перспективы для создания гибких, управляемых событиями приложений. Одно приложение публикует информацию в сети, а другое подписывается для получения данных по интересующей его теме. Взаимодействующие таким способом приложения полностью независимы друг от друга и могут ничего не знать о существовании, физическом размещении и состоянии друг друга. Это открывает путь к динамической реконфигурации всей распределенной системы, добавлению и произвольному изменению любых клиентов и серверов без прерывания их работы и полной изоляции прикладных компонентов от любых аспектов реализации других частей системы. В конечном итоге, это означает возможность эффективной интеграции различных бизнес-приложений в единое корпоративное решение.

  Характерным примером распределенной системы на основе модели публикации/подписки является система TIB/Rendezvous компании TIBCO. Ключевой механизм, лежащий в основе системы TIB/Rende­zvous, – это адресация по теме (subject-based addressing). При таком подходе процесс, который собирается посылать сообщение, не может определить точное место назначения. Вместо этого он именует сообщение названием темы (subject name), после чего посылает его в коммуникационную систему для пересылки по сети. Получатели, в свою очередь, не выясняют, от каких процессов они собирают­ся получать сообщения. Вместо этого они сообщают коммуникационной систе­ме, какие темы их интересуют. Коммуникационная система гарантирует, что по­лучателю будут доставлены только те сообщения, которые несут данные по теме, интересующей получателя.

  Отправка сообщения методом адресации по теме также называется публика­цией (publishing). Чтобы получить сообщение по определенной теме, процесс дол­жен подписаться на эту тему. Принципиальная схема организации системы публикации/под­писки, реализованная в TIB/Rendezvous, показана на рис. 2.6.

  Основой архитектуры системы TIB/Rendezvous являет­ся сеть с поддержкой групповой рассылки, хотя по возможности допускается ис­пользование более эффективных средств связи (так, например, если известно точное местонахождение подписчика, обычно выполняется сквозная передача со­общений). На каждом узле этой сети работает демон контактов (rendezvous dae­mon), который отвечает за то, чтобы сообщения отсылались и получались в соот­ветствии с темой. Когда сообщение публикуется, демон контактов осуществляет его групповую рассылку всем узлам сети. Обычно групповая рассылка реализуется средствами базовой сети, такими как групповая рассылка по IP-адресам или аппаратная широковещательная рассылка.

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

      

 

  Рис. 2.6. Принципиальная схема организации системы

публикации/под­писки

 

  Чтобы система могла вырасти до размера больших сетей, таких как глобальные сети, используются также маршрутизирующие демоны контактов (rendezvous router daemons). Обычно каждая локальная сеть имеет одного маршрутизирующего де­мона контактов. Этот демон связывается с маршрутизирующим демоном другой удаленной сети. Маршрутизирующие демоны образу­ют сквозную оверлейную сеть (overlay network), в которой маршрутизаторы со­единены между собой попарно соединениями TCP. Вторичная сеть – это сеть маршрутизаторов прикладного уровня. Каждый маршрутизатор знает топологию вторичной сети и вычисляет дерево групповой рассылки для публикации сообщений в других сетях. Маршрутизато­ры рассылают только те сообщения, которые публикуются в их локальной сети. Сообщения из других сетей пересылаются по дереву групповой рассылки той се­ти, из которой они первоначально исходили.

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

  Технологической основой для всех сред обмена сообщениями нового поколения стала спецификация JMS (Java Message Service – служба сообщений Java), в деталях определяющая, как взаимодействуют клиенты и серверы в среде асинхронных сообщений. К числу достоинств JMS относится то, что она соответствует современным представлениям о взаимодействии приложений и не требует специальных знаний и доступна для любого программиста, работающего на языке Java. Этими качествами она заметно отличается от инструментария MQSeries, где необходима специальная подготовка. Еще один стимул для рождения нового поколения MOM – появление расширяемого языка разметки данных XML (eXtensible Markup Language – «расширяемый язык разметки») для Internet-приложений, позволяющего одним приложениям «понимать» другие.

    Спецификация JMS построена на основе топологии «ступицы и колеса» (hub-and-spoke), в которой все приложения подключаются к центральному процессу, называемому сервером сообщений (message server). Он отвечает за корректность маршрутизации сообщений, аутентификацию и авторизацию пользователей. Сами приложения рассматриваются как клиенты – они могут быть передатчиками и/или приемниками. При этом обеспечивается такой API-интерфейс на базе Java, который позволяет разработчикам писать клиентские приложения, не заботясь о том, какое конкретно программное обеспечение MOM будет использоваться. Спецификация только определяет доступ к корпоративной системе обмена сообщениями, а каждый производитель ПО, опирающийся на JMS, самостоятельно разрабатывает инструменты для администрирования среды обмена сообщениями. JMS стала основой целого направления программных продуктов категории MOM, таких как MQ Express компании Talarian, SonicMQ компании Progress Software, Bus компании Softwired, FioranoMQ компании Fiorano Software и других.

2.5. Распределенная обработка информации

на основе моделей согласования

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

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

  Другой тип согласования наблюдается в том случае, если процессы не связа­ны по времени, но связаны по ссылкам. Такой тип согласования называют согласованием через почтовый ящик (mailbox coordination). В этом случае для взаимодействия не нужно, чтобы два взаимодействующих друг с другом процесса выполня­лись одновременно. Вместо этого взаимодействие происходит путем посылки со­общений в почтовый ящик, может быть, используемый совместно. При этом необходимо явно указать адрес почтового ящика, в котором должны храниться сообщения. Это и есть ссылочная связность.

  Комбинация связности по времени и несвязности по ссылкам образует груп­пу моделей согласования на встрече (meeting-oriented coordination). В несвязной по ссылкам системе процессы не имеют полной информации друг о друге. Дру­гими словами, когда процесс хочет согласовать свою деятельность с другими про­цессами, он не может обратиться к ним напрямую. Взамен используется метафора встречи, на которой собираются процессы, чтобы скоординировать свою дея­тельность. Модель предполагает, что процессы, участвующие во встрече, выпол­няются одновременно.

  Наиболее распространенный вариант согласования – это сочетание несвяз­ных по времени и по ссылкам процессов. Этот вариант представлен генеративной связью (generative communication), которая впервые была реализована в программной системе Linda. Основная идея генеративной связи состоит в том, что набор независимых процессов может использовать разделяемое сохранное пространст­во данных, организуемое с помощью кортежей. Кортежи – это именованные за­писи, содержащие несколько (но, возможно, и ни одного) типизованных полей. Процесс может помещать в разделяемое пространство данных записи любого ти­па (то есть генерировать связующие записи). Для разделения кортежей в соответствии с информацией, которая в них со­держится, достаточно их имен.

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

    Примером системы согласования является система Jini («джини») компании Sun Microsystems. Отнесение Jini к системам согласования основано в первую очередь на том, что эта система способна поддерживать гене­ративную связь при помощи Linda-подобной службы под названием JavaSpace. Однако существует множество служб и средств, которые делают Jini больше, чем просто системой согласования.

  Jini – это распределенная система, состоящая из разных, но взаимосвязанных элементов. Она жестко привязана к языку программирования Java, хотя многие из ее принципов равно могут быть реализованы и при помощи других языков. Важной частью системы явл

---

---