48479

Распределенные информационные системы

Конспект

Информатика, кибернетика и программирование

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

Русский

2013-12-10

2.91 MB

367 чел.

Распределенные информационные системы

(конспект лекций)


Тема 1. Введение в распределенные системы (3 ч)

Понятие распределенной системы обработки информации. Виды и свойства распределенных систем. Архитектура программного обеспечения информационных систем. Управление взаимодействием разнородных приложений (middleware).

1. Что такое распределенная система?

2. Основные задачи распределенной обработки

3. Концепции аппаратных решений

4. Концепции программных решений

5. Модель Клиент-сервер

6. Итоги

1. Что такое распределенная система?

В литературе упоминаются разные определения понятия распределенной системы (РС), но все они могут быть сведены к следующим определениям (Таненбаум):

1. Распределенная система – это набор независимых компьютеров, представляющийся их пользователям как единая система.

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

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

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

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

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

2. Основные задачи распределенной обработки

Какие основные задачи распределенных систем?

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

Для решения этой основной задачи, РС должна удовлетворять следующим требованиям:

  1.  Прозрачность.
  2.  Открытость.
  3.  Гибкость.
  4.  Масштабируемость (расширяемость).

2.1. Прозрачность

Важная задача РС состоит в том, чтобы скрыть тот факт, что процессы и ресурсы физически распределены по разным компьютерам. РС, которые представляются пользователям и приложениям в виде единой системы называются прозрачными (transparent).

Концепция прозрачности применима к разным аспектам РС, а именно:

Прозрачность доступа. Цель – скрыть разницу в способах представления и передачи данных между разными типами ПК и ОС, способах представления имен файлов, правил работы с ними и др.

Прозрачность местоположения. Цель – скрыть реальное физическое размещение ресурса. Важную роль в реализации этого играет именование.

Прозрачность переноса. Цель – скрыть факт физического перемещения ресурса. При этом смена местоположения не влияет на доступ.

Прозрачность смены местоположения – отличается от предыдущего тем, что местоположение ресурса может произойти при его использовании. Пример - мобильные пользователи.

Прозрачность репликации (дублирования). Цель - скрыть факт наличия нескольких копий ресурса.

Прозрачность параллельного доступа. Цель – скрыть от пользователя факт совместного использования ресурса. При этом обеспечивается целостность и непротиворечивость ресурса (например, механизм блокировок в БД).

Прозрачность отказов. Цель – обеспечить нормальную работу при наличии отказов (или скрыть факт отказа и не уведомлять об этом пользователя). Пример – при работе с перегруженным Web-сервером браузер выжидает нужное время, а потом сообщает о недоступности страницы.

Не все эти атрибуты должны быть полностью реализованы в РС, поскольку обеспечение прозрачности влияет на производительность.

2.2. Открытость

Открытая РС (open distributed system) – это система, предлагающая службы, вызов которых требует стандартные синтаксис и семантику. Например, в сетях формат сообщений должен соответствовать протоколам.

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

Открытые РС должны иметь такие свойства как:

- Интероперабильность (способность к взаимодействию);

- Переносимость (из одной системы в другую без изменения интерфейсов);

- Гибкость – легкость конфигурирования системы, состоящей из разных компонентов. То есть РС должна быть расширяемой программно и аппаратно.

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

2.3. Масштабируемость (возможность расширения)

Масштабируемость системы может измеряться по трем разным показателям:

  1.  размер – легкость подключения к ней новых пользователей и ресурсов;
  2.  площадь – пользователи и ресурсы могут быть разнесены в пространстве;
  3.  управление – система проста в управлении при работе во многих административно независимых организациях.

Эта характеристика РС может снижать производительность.

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

В качестве примеров ограничения масштабируемости можно привести:

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

Проблемы географической масштабируемости – неэффективность блокировок доступа к общим ресурсам (как в локальных сетях).

Технологии масштабирования.

Основные технологии: сокрытие времени ожидания связи, распределение и репликация.

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

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

Особенно это касается проверки данных на форме, т.е. эффективнее переместить на сторону клиента проверку данных всех полей формы.

2. Распределение. Предполагает разбиение компонентов на более мелкие части с последующим их распределением в системе. Пример – система доменных имен Интернета (DNS). Пространство DNS организовано иерархически в виде дерева доменов (domains) разбитых на зоны (по странам и областям деятельности). Имена каждой зоны обрабатываются отдельным сервером имен.

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

Второй пример – Web. Каждый документ имеет уникальное имя URL. Физически среда Web разнесена по многим серверам. Имя сервера, содержащего конкретный документ, определяется по его URL-адресу. Это позволяет наращивать количество документов без потери производительности.

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

Особую форму репликации представляет собой кеширование (caching). Хотя отличия между ними незначительны. Как и при репликации, результатом кеширования является создание копии ресурса, обычно в непосредственной близости от клиента. В отличие от репликации кеширование – это действие, предпринимаемое со стороны клиента, а не сервера.

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

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

3. Концепции аппаратных решений

Существуют разные способы организации процессоров в единую РС (вариантов соединения и организации взаимного обмена).

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

Мультикомпьютерные системы разделяют также на гомогенные (homogeneous) и гетерогенные (heterogeneous). В первых используется одна компьютерная сеть, использующая единую технологию, однотипные процессоры. Такие системы часто используются в качестве параллельных (как и мультипроцессорные). Пример –кластеры рабочих станций.

Гетерогенные системы содержат независимые компьютеры, соединенные разными сетями (например, могут состоять из нескольких локальных сетей, соединенных коммутируемой магистралью FDDI или ATM).

4. Концепции программных решений

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

Эти функции обычно выполняют ОС. Для распределенных компьютеров ОС можно разделить на две категории: сильно связанные и слабо связанные. Сильно связанные ОС обычно называются распределенными ОС (Distributed Operation System, DOS) и используются для управления мультипроцессорными и гомогенными мультикомпьютерными системами. Основная их цель – скрыть тонкости управления аппаратным обеспечением.

Слабо связанные ОС называются сетевыми ОС (Network Operation System, NOS). Они используются для управления гетерогенными мультикомпьютерными системами. Помимо традиционных функций управления ресурсами, они должны обеспечить доступ удаленных клиентов к локальным службам.

Для создания РС служб сетевой ОС недостаточно. Необходимо добавить к ним дополнительные компоненты для организации поддержки прозрачности распределения. Эти компоненты образуют средства промежуточного уровня (middleware). Таким образом, основную роль в построении РС играют программные средства (службы) промежуточного уровня, между ОС и распределенными приложениями. На рис. 1 приведена общая структура РС с промежуточным уровнем.

Рис. 1.1 Общая структура РС с промежуточным уровнем.

Модели промежуточного уровня.

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

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

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

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

Службы (сервисы) промежуточного уровня

Эти службы предназначены для обеспечения основных характеристик РС, прежде всего прозрачности, открытости и масштабируемости. Все ПО промежуточного уровня должно поддерживать прозрачность доступа путем предоставления высокоуровневых средств связи, скрывающих низкоуровневую пересылку сообщений по сети. Интерфейс транспортного уровня (IP), который предоставляется сетевой ОС, полностью заменяется другими средствами. Способ, которым поддерживается связь, зависит от модели распределения, предлагаемой ПО промежуточного уровня. Это упоминавшийся нами RPC и системы распределенных объектов. Кроме того, системы промежуточного уровня предоставляют средства для прозрачного доступа к распределенным БД, файловым системам, документам Web.

Важная служба, общая для всех систем промежуточного уровня – именование (naming). В Web любой документ поименован посредством URL, содержащим имя сервера, на котором находится документ с данным URL.

Другая важная служба – обеспечение сохранности данных. Пример – механизм распределенных транзакций.

Еще одна важная общая служба – обеспечение защиты программ и данных. Основная проблема защиты в системах промежуточного уровня – в распределенности. В сочетании с требованием расширяемости защита превращается в одну из наиболее трудно реализуемых в РС служб.

5. Модель Клиент-сервер

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

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

Рис. 1.2 Модель взаимодействия клиент-сервер

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

Рассмотрим некое типичное приложение, которое в соответствие с современными представлениями может быть разделено на следующие логические уровни (рис.1.3).

Рис. 1.3 Логические уровни приложения

Уровень интерфейса обычно реализуется на клиенте, что вполне естественно.

На уровне обработки обычно реализуется основная бизнес-логика приложения (функциональность).

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

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

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

Варианты архитектуры клиент-сервер

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

1. Клиентские машины (рабочие станции), на которых устанавливаются программы-клиенты, реализующие интерфейс.

2. Серверы, реализующие все остальное, то есть уровни обработки и данных.

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

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

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

Архитектуру построенных по такому принципу называют клиент-серверной или двухзвенной (two-tiered architecture) (рис. 1.4). Хотя подобные системы часто не относят к классу распределенных, но формально они могут считаться простейшими представителями распределенных систем.

Рис. 1.4 Двухзвенная архитектура

Развитием архитектуры клиент-сервер является трехзвенная архитектура (three-tiered architecture), в которой интерфейс пользователя, логика приложения и доступ к данным выделены в самостоятельные составляющие системы, которые могут работать на независимых компьютерах (рис. 1.5).

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

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

Рис. 1.5. Трехзвенная архитектура

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

Главная его особенность – это размещение логически разных компонентов на разных машинах. 

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

Таким образом, в обиходе под распределенной системой часто подразумевают рост многозвенной архитектуры «в ширину», когда запросы пользователя не проходят последовательно от интерфейса пользователя до единственного сервера баз данных.

В современных архитектурах подобное распределение на клиенты и серверы называется горизонтальным распределением. При таком типе распределения клиент или сервер может содержать физически разделенные части логически однородного модуля, причем работа с каждой из частей может происходить независимо (рис. 1.6).

Рис. 1.6. Компоненты распределенной системы

Пример – web-сервер, реплицированный на несколько машин в локальной сети. При изменении одной Web-страницы – изменения рассылаются по всем серверам. Сервер, которому будет передан приходящий запрос, выбирается по принципу «карусели». Такая форма распределения используется для выравнивания нагрузки на серверы популярных web-сайтов.

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

Есть и другие варианты организации архитектур, например, которые распределены как вертикально, так и горизонтально.

6. Итоги

Распределенные системы (РС) состоят из автономных компьютеров, работающих совместно, в виде единой связной системы. Их преимущества по сравнению с монолитными системами:

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

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

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

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

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

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


Тема 2. Модели взаимодействия компонентов РС (2 часа)

2.1 Понятие промежуточной среды

2.2 Модели взаимодействия компонентов

2.1 Понятие промежуточной среды

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

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

Примечание:

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

Использование протокола TCP/IP посредством сокетов предоставляет стандартный, межплатформенный, но низкоуровневый сервис для обмена данными между компонентами. Для выполнения сформулированных выше требований к распределенным системам функции сеансового и представительского уровня должна взять на себя промежуточная среда (middleware), называемая так же промежуточным программным обеспечением (рис. 2.1). Такая среда должна помочь создать разработчиками открытые, масштабируемые и устойчивые распределенные системы. Для достижения этой цели промежуточная среда должна обеспечить службы для взаимодействия компонент распределенной системы. К таким службам относятся:

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

– обеспечение безопасности распределенной системы: аутентификация и авторизация всех пользователей сервисов компоненты и защита передаваемой между компонентами информации от искажения и чтения третьими сторонами;

– обеспечение целостности данных: управление транзакциями, распределенными между удаленными компонентами системами;

– балансировка нагрузки на серверы с программными компонентами;

– обнаружение удаленных компонент.

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

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

Рис. 2.1 Модель взаимодействия вычислительных систем

Примечание:

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

Набор протоколов в модели OSI  называется стеком протоколов.

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

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

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

Физический уровень отвечает за передачу сигналов (0 и 1). Таким образом, протоколы этого уровня отвечают за стандартизацию электрических, механических и сигнальных интерфейсов. Существует много стандартов физического уровня для разных носителей и линий связи. Например, RS-232, Ethernet, Fast Ethernet, FDDI.

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

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

В настоящее время наиболее популярным сетевым протоколом является не требующий установки соединения протокол Интернета IP (Internet Protocol).

На сетевом уровне сообщение именуется термином пакет.  

Другим протоколом, который приобретает все большую популярность является протокол с соединением, который называется виртуальный канал на базе сетей АТМ. Виртуальный канал в АТМ – это непрямое соединение, устанавливаемое от источника к приемнику, возможно проходящее через несколько промежуточных АТМ-коммутаторов. Набор виртуальных каналов группируется в виртуальный путь (сравним с предопределенным маршрутом между двумя узлами, вдоль которого выстраиваются его виртуальные каналы).

Транспортные протоколы.

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

Основная задача транспортных протоколов – обеспечить гарантированно надежную связь (без потерь данных и в нужном порядке).  

Транспортный протокол для Интернета называется протоколом управления передачей (Transmission Control Protocol, TCP).

Комбинация протоколов TCP/IP в настоящее время является фактически стандартом сетевых взаимодействий. Комплект протоколов Интернета также включает в себя не требующий соединения транспортный протокол UDP (Universal Datagram Protocol – универсальный протокол датаграмм), являющийся модификацией IP.

Протоколы верхнего уровня.

В модели OSI поверх транспортного уровня находятся еще 3: сеансовый, представительский и прикладной.

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

Уровень представления. Отвечает за правильную интерпретацию сообщений (семантику). Это упрощает взаимодействие между машинами с разным внутренним представлением данных.

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

2.2 Модели взаимодействия компонентов РС

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

1) обмен сообщениями между компонентами;

2) и вызов процедур или методов объекта удаленной компоненты по аналогии с локальным вызовом процедуры.

Поскольку в настоящее время любое взаимодействие между удаленными компонентами в конечном итоге основано на сокетах TCP/IP, первичным с точки зрения промежуточной среды является низкоуровневый обмен сообщениями на основе сетевых сокетов, сервис которых никак не определяет формат передаваемого сообщения. На базе протоколов TCP или HTTP затем могут быть построены прикладные протоколы обмена сообщений более высокого уровня абстракции для реализации более сложного обмена сообщениями или удаленного вызова процедур.

Удаленный вызов является моделью, происходящей от языков программирования высокого уровня, а не от реализации интерфейса транспортного уровня сетевых протоколов. Поэтому протоколы удаленного вызова должны обязательно базироваться на какой-либо системе передачи сообщений, включая как непосредственное использование сокетов TCP/IP, так и основанные на нем другие промежуточные среды для обмена сообщениями. Реализация высокоуровневых служб обмена сообщениями, в свою очередь, может использовать удаленный вызов процедур, основанный на более низкоуровневой передаче сообщений, использующей, например, непосредственно сетевые сокеты. Таким образом, одна промежуточная среда может использовать для своего функционирования сервисы другой промежуточной среды, аналогично тому, как один протокол транспортного или сетевого уровня может работать поверх другого протокола.

2.2.1 Обмен сообщениями

Явный обмен сообщениями между процессами является основой многих РС.

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

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

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

Существует несколько разработок в области промежуточного программного обеспечения, реализующие высокоуровневые сервисы для обмена сообщениями между программными компонентами. К ним относятся, в частности, Microsoft Message Queuing, IBM MQSeries и Sun Java System Message Queue. Такие системы дают возможность приложениям использовать следующие базовые примитивы по использованию очередей:

– добавить сообщение в очередь;

– взять первое сообщение из очереди, процесс блокируется до появления в очереди хотя бы одного сообщения;

– проверить очередь на наличие сообщений;

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

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

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

Рис. 2.1. Системы очередей сообщений

Использование очередей сообщений ориентировано на асинхронный обмен данными.

Основные достоинства таких систем:

– время функционирования сервера может быть не связано со временем работы клиентов;

– независимость промежуточной среды от средства разработки компонент и используемого языка программирования;

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

Недостатки систем очередей сообщений являются продолжением их достоинств:

– необходимость явного использования очередей распределенным приложением;

- сложность реализации синхронного обмена;

– определенные накладные расходы на использование менеджеров очередей;

– сложность получение ответа: передача ответа может потребовать отдельной

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

2.2.2 Удаленный вызов процедур

Идея удаленного вызова процедур (remote procedure call, RPC) появилась в середине 80-х годов и заключалась в том, что при помощи промежуточного программного обеспечения функцию на удаленном компьютере можно вызывать так же, как и функцию на локальном компьютере. Чтобы удаленный вызов происходил прозрачно с точки зрения вызывающего приложения, промежуточная среда должна предоставить процедуру-заглушку (stub), которая будет вызываться клиентским приложением. После вызова процедуры-заглушки промежуточная среда преобразует переданные ей аргументы в вид, пригодный для передачи по транспортному протоколу, и передает их на удаленный компьютер с вызываемой функцией. На удаленном компьютере параметры извлекаются промежуточной средой из сообщения транспортного уровня и передаются вызываемой функции (рис. 2.2). Аналогичным образом на клиентскую машину передается результат выполнения вызванной функции.

Рис. 2.2. Удаленный вызов процедур

Например, необходимо из процесса, запущенного на машине А вызвать процедуру на машине В. Информация может быть передана через параметры и возвращена в виде результата. При этом программист не должен замечать, откуда вызывается процедура (прозрачность доступа).

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

Модель, с помощью которой реализуется такое взаимодействие, называется Удаленный вызов процедур (Remote Procedure Call, RPC). Это один из ранних методов организации связи, лежащий в основе многих современных технологий РС.

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

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

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

Существует три возможных варианта удаленного вызова процедур.

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

2. Однонаправленный асинхронный вызов: клиент продолжает свое выполнение, получение ответа от сервера либо отсутствует, либо его реализация возложена на

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

3. Асинхронный вызов: клиент продолжает свое выполнение, при завершении сервером выполнения процедуры он получает уведомление и результат ее выполнения, например через callback-функцию, вызываемую промежуточной средой при получении результата от сервера.

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

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

Удаленность вносит дополнительные проблемы. Выполнение вызывающей программы и вызываемой локальной процедуры в одной машине реализуется в рамках единого процесса. Но в реализации RPC участвуют как минимум два процесса — по одному в каждой машине.

В случае работы с удаленной процедурой, основное отличие состоит в том, что вызов удаленной процедуры обслуживают два процесса: клиентский процесс и серверный процесс.

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

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

Рис. 2.3.

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

Между вызовами локальных и удаленных процедур есть еще несколько важных отличий:

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

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

3. Производительность. Скорость выполнения удаленных процедур, как правило на один или два порядка ниже скорости выполнения аналогичных локальных процедур.

4. Аутентификация. Поскольку вызовы удаленных процедур происходят по сети, необходимо использовать механизмы аутентификации клиента.

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

Механизм работы RPC

Рассмотрим, как происходит RPC вызов. Программист создает клиентскую и серверную часть приложения (в качестве серверной части может выступать системный сервис, входящий в поставку соответствующих ОС). Клиентская и серверная части запускаются на различных машинах, соединенных в сеть. Функциональный вызов перехватывает так называемая заглушка (Stub-процедура), которая перенаправляет локальный вызов в RPC-библиотеку времени-выполнения, в ней происходит преобразование данных под существующий транспортный протокол. Данные и служебная информация переносятся по сети, декодируются в RPC-библиотеке времени-выполнения, расположенной на сервере, и через заглушку попадают на серверную часть приложения. В серверной ПЭВМ запускается соответствующий запросу программный код и результаты его работы по уже известной схеме передаются клиенту. RPC может работать и локально. При локальном вызове весь процесс передачи параметров происходит в одном адресном пространстве.

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

2.2.3 Обращение к удаленным объектам (RMI)

Технология RMI (Remote Method Invocation) – это развитие RPC (его объектная реализация).

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

RMI (Remote Method Invocation, т.e. вызов удаленного метода), которая интегрирована с JDK1.1, является продуктом компании JavaSoft и реализует распределенную модель вычислений. RMI позволяет клиентским и серверным приложениям через сеть вызывать методы клиентов/серверов, выполняющихся в Java Virtual Machine. Хотя RMI считается легковесной и менее мощной, чем CORBA и DCOM тем не менее, она обладает рядом уникальных свойств, таких как распределенное, автоматическое управление объектами и возможность пересылать сами объекты от машине к машине.

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

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

При обращении клиента к распределенному объекту управление передаётся программе реализации интерфейса объекта аналогичной клиентской заглушке и называется посредником (proxy). Посредник осуществляет транзит параметров от вызывающей программы к ОС клиентской ЭВМ и обратно как это делает клиентская заглушка. На стороне сервера транзит параметров от ОС сервера к методам объекта и обратно осуществляет аналог серверной заглушке, называемой программа скелетон (каркас). Объекты распределенных систем существуют в формах принятых в том или ином языке программирования (рис. 2.4).

Рис. 2.4. Использование удаленных объектов

Client Stub (переходник для клиента) и Server Stub (переходник для сервера) порождены от общего интерфейса, но различие между ними в том, что client stub служит просто для подсоединения к RMI Registry, а server stub используется для связи непосредственно с функциями сервера.

Для описания жизненного цикла в системах с удаленными объектами используются два

дополнительных понятия:

– активация объекта: процесс перевода созданного объекта в состояние обслуживания удаленного вызова, то есть связывания его с каркасом и посредником.

– деактивация объекта: процесс перевода объекта в неиспользуемое состояние.

Выделяют три модели использования удаленных объектов:

– модель единственного вызова (singlecall),

- модель единственного экземпляра (singleton),

- модель активации объектов по запросу клиента (client activation).

Первых две модели так же иногда называют моделями серверной активации (server activation), хотя, строго говоря, активация всегда происходит на сервере после какого-либо запроса от клиента.

2.2.4 Связь на основе потоков данных

Применяется при передаче информации не имеющей четких ограничений по объему и времени передачи.

Различают три режима передачи потоков данных:

1. Асинхронный режим. Временные ограничения на передачу потоков данных не накладываются.

2.  Синхронный режим. Для каждого элемента потоков данных определяется максимально возможная задержка передачи.

3. Изохронный режим. Для каждого элемента данных определяется как максимально возможная, так и минимальная задержка передачи данных.

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

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


Тема 3. Распределенные системы объектов (4 часа)

3.1 Задачи построения РИС

3.2 Corba

3.3  Модели распределенных объектов Microsoft COM, DCOM, COM+

  1.  Задачи построения РИС

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

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

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

Преимущества использования

Использование технологии распределенных объектов позволяет пользоваться всеми преимуществами объектно-ориентированного подхода:

  •  сокращение времени разработки (изолированная разработка)
  •  сокращение количества ошибок
  •  повторное использование программных компонент
  •  легче становится будущее изменение системы.

Еще одним важным достоинством таких систем является возможность построения так называемых тонких клиентов.

Повторное использование кода

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

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

Изолированная разработка

Из-за своей модульной основы распределенные приложения позволяют осуществить изолированные друг от друга создание и изолированное изменение модулей (компонент).

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

Сопровождение приложений

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

Тонкие клиенты

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

3.2 Объектная модель CORBA

В конце 1980-х и начале 1990-х годов многие ведущие фирмы-разработчики были заняты поиском технологий, которые принесли бы ощутимую пользу на рынке компьютерных разработок. В качестве такой технологии была определена область распределенных компьютерных систем. Необходимо было разработать единообразную архитектуру, которая позволяла бы осуществлять повторное использование и интеграцию кода, что было особенно важно для разработчиков. В 1989 была сформирована OMG (Object Managment Group) и сегодня OMG насчитывает более 700 членов (в OMG входят практически все крупнейшие производители ПО, за исключением Microsoft).

Задачей консорциума OMG является определение набора спецификаций, позволяющих строить распределенные информационные системы. Для этого была создана открытая архитектура и набор стандартов, которые объединены в понятии OMA (Object Managment Architecture).

Задача CORBA (Common Object Request Broker Architecture) — осуществить интеграцию изолированных систем, дать возможность программам, написанным на разных языках, работающим на разных узлах сети, взаимодействовать друг с другом так же просто, как если бы они находились в адресном пространстве одного процесса.

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

Главными компонентами стандарта CORBA являются:

  •  брокер объектных запросов (Object Request Broker);
  •  язык определения интерфейсов (Interface Definition Language).

В спецификацию CORBA включено также несколько дополнительных, но важных служб:

служба динамического формирования запросов (DII);

служба репозитория интерфейсов (IR);

служба динамической обработки запросов (DSI);

службы личных брокеров запросов (GIOP).

Характерные особенности разработок РС по технологии CORBA заключаются в следующем:

Язык описания интерфейсов OMG IDL позволяет определить интерфейс, независимый от языка реализации.

Высокий уровень абстракции CORBA в семиуровневой модели OSI избавляет программиста от работы с низкоуровневыми сетевыми протоколами.

Программисту не требуется информация о месте сервера в сетевой ИС и способе его активации.

Разработка клиентской программы не зависит от серверной операционной системы и аппаратной платформы.

Объектная модель CORBA

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

Брокер объектных запросов (Object Request Broker - ORB)

Главный компонент CORBA — брокер объектных запросов. Его задачей является предоставление механизма выполнения запроса объекта-клиента: поиск объекта, к которому относится данный запрос, передача необходимых данных, подготовка объекта к обработке. Брокер обеспечивает прозрачное взаимодействие клиентского и серверного приложений. Для разработчика вызов методов удаленных объектов не отличается от обычных локальных вызовов.

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

Клиент может запрашивать выполнение операций с помощью ORB несколькими способами. Возможные варианты взаимодействия объектов показаны на рисунке.

Dynamic Invocation Interface (DII): позволяет клиенту находить серверы и вызывать их методы во время работы системы.

IDL Stubs: определяет, каким образом клиент производит вызов сервера.

ORB Interface: общие как для клиента, так и для сервера службы (сервисы).

IDL Skeleton: обеспечивает статические интерфейсы для объектов определенного типа. Dynamic Skeleton Inerface: общие интерфейсы для объектов, независимо от их типа, которые не были определены в IDL Skeleton.

Object Adapter: осуществляет коммуникационное взаимодействие между объектом и ORB.

Вызов операций разделяемого объекта-сервера может быть статическим, через IDL-заглушку, или динамическим (Dynamic Invocation Interface). В случае статического вызова описания интерфейсов на IDL отображаются в программный код на языках С, С++, Smalltalk и др. При использовании динамического интерфейса запросы формируются специальным образом, без отображения интерфейса объекта в исходный код разрабатываемого приложения.

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

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

Базовый объектный адаптер BOA

Спецификация OMG CORBA определяет базовый объектный адаптер, который должен быть реализован во всех брокерах запросов. Basic Object Adapter (BOA) — это набор интерфейсов для создания ссылок на удаленные объекты, регистрации объектов, авторизации запросов и активизации приложений.

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

генерация ссылок на удаленные объекты;

вызов методов, определенных в IDL;

обеспечение безопасности взаимодействия;

активация и деактивация объектов;

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

регистрация объектов.

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

IDL — язык описания интерфейсов

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

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

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

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

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

Отображение также является предметом стандартизации OMG. В настоящее время стандартизованы отображения для Ada, C, C++, Lisp, Smalltalk, Java, COBOL, PL/I и Python

Рисунок  CORBA IDL отображения в модели Клиент/Сервер. 

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

Структура CORBA IDL файла выглядит следующим образом:

module <identifier> {

             <type declarations>;

             <constant declarations>;

             <exception declarations>;

             interface <identifier> [:<inheritance>] {

               <type declarations>;

               <constant declarations>;

               <attribute declarations>;

               <exception declarations>;

               [<op_type>]<identifier>(<parameters>)

               [raises exception] [context]

                 .

                 .

               [<op_type>]<identifier>(<parameters>)

               [raises exception] [context]

                 .

                 .

             }

interface <identifier> [:<inheritance>]

                 .

                 .

}

Динамический интерфейс вызова (DII)

DII-интерфейс (DII - Dynamic Invocation Interface) позволяет приложениям клиентов формировать произвольные запросы к объектам-серверам, интерфейсы которых неизвестны на стадии компиляции клиентского приложения. Информация о структуре интерфейса, к которому обращается клиент для вызова соответствующей операции, может быть получена во время работы программы, если известны имя операции и список параметров и имеется ссылка на соответствующий объект-сервер. Практически DII дает возможность вести разработку клиентских и серверных программ раздельно.

Репозиторий интерфейсов (Interface Repository)

Репозиторий интерфейсов (Interface Repositary), содержит определения интерфейсов на IDL, позволяет видеть интерфейсы доступных серверов в сети и программировать их использование в программах-клиентах.

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

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

Физически репозиторий интерфейсов является программным компонентом, имеющим собственный IDL-интерфейс. Через этот интерфейс различные приложения и получают данные о других CORBA-объектах.

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

Протоколы взаимодействия различных объектных брокеров (GIOP, IIOP)

Основной задачей спецификации CORBA является обеспечение взаимодействия объектов, распределенных по разнородной сети и использующих в общем случае различные брокеры запросов. Для связи между брокерами был разработан протокол General Inter ORB Protocol (GIOP), стандартизующий низкоуровневое представление данных и множество форматов сообщений.

GIOP - абстрактный протокол в стандарте CORBA, обеспечивающий взаимодействие брокеров. Архитектура GIOP включает несколько конкретных протоколов:

  1.  Internet InterORB Protocol (IIOP) - Межброкерный протокол для Интернет, это протокол для организации взаимодействия между различными брокерами, опубликованный консорциумом OMG. IIOP используется GIOP в среде Интернет, и обеспечивает отображение сообщений между GIOP и TCP/IP, то есть, определяет обмен сообщениями в формате GIOP через TCP/IP-соединения..
  2.  SSL InterORB Protocol (SSLIOP) - это IIOP поверх SSL, поддерживаются шифрование и аутентификация.
  3.  HyperText InterORB Protocol (HTIOP) - это IIOP поверх HTTP.

При необходимости протокол GIOP может быть реализован на основе других транспортных протоколов, например, IPX/SPX. Иерархия спецификаций взаимодействия брокеров запросов по стандарту CORBA изображена на рисунке.

Основные службы (сервисы) стандарта CORBA

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

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

Рисунок Трехуровневая архитектура информационных систем.

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

Служба событий (Event service) обеспечивает поддержку асинхронного взаимодействия приложений.

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

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

Служба связи (Relationship service) реализует логические связи между CORBA-объектами. Служба определяет два дополнительных типа объектов: связь и роль. Роль представляет собой CORBA-объект, отражающий характер связи, а связь характеризует зависимости объектов прикладной области.

Служба управления разделяемыми ресурсами (Concurrency control service )позволяет клиентам координировать свои действия при использовании разделяемых ресурсов. Управление разделяемыми ресурсами осуществляется с помощью блокировок. Каждая блокировка ассоциируется с единственным ресурсом и единственным клиентом. Служба определяет несколько режимов блокировок, которые соответствуют различным способам доступа.

Служба внешнего представления (Externalization service) формирует копию CORBA-объекта в виде некоторого внешнего представления — файла, элемента базы данных и т.д.

Object Management Architecture

Осенью 1990 года OMG впервые опубликовала документ Object Management Architecture Guide (OMA Guide). Он был подкорректирован в сентябре 1992. Детали Common Facilities (Общие средства) были добавлены в январе 1995. Следующий рисунок показывает четыре основные элемента этой архитектуры:

Object Request Broker определяет объектную шину CORBA.

Common Object Services представляют собой коллекцию служб, снабженных объектными интерфейсами и обеспечивающих поддержку базовых функций объектов.

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

Application Objects  прикладные бизнес-объекты и приложения, которые являются основными потребителями всей CORBA инфраструктуры.

Common Facilities - (общие средства) заполняют пространство между ORB и объектными службами с одной стороны, и прикладными службами, с другой. Таким образом, ORB обеспечивает базовую инфраструктуру, Object Services — фундаментальные объектные интерфейсы, а задача Common Facilities — поддержка интерфейсов сервисов высокого уровня, которые, впрочем, могут включать специализацию Object Services. Таким образом, операции, представляемые Common Facilities, предназначены, в частности, для использования Object Services и прикладными объектами. Реализуется это посредством наследования стандартных Интерфейсов.

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

Application Objects - объекты, если они участвуют в обмене с ORB, должны определятся с помощью IDL. Обычно приложения состоят из нескольких взаимодействующих бизнес-объектов. И, как правило, приложения-объекты строятся поверх предоставляемых ORB, Common Facilities и Object Facilities сервисов. Суть для заказчиков (или системных интеграторов) заключается в том, чтобы собрать разные бизнес-объекты в одну систему, при том, вне зависимости от производителя.

Сравнение RPC и ORB

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

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

Достоинства ORB

В теории, CORBA представляется как лучшая клиент/сервер middleware-система, но на практике она хороша лишь настолько, насколько хороши продукты, ее реализующие. К основным коммерческим ORB относятся: Orbix от фирмы IONA Technologies; DSOM от IBM; ObjectBroker от Digital; JOE от Sun; Visibroker от Visigenic и Netscape; ORB+ от HP.

Небольшой список достоинств, которыми обладает каждая CORBA ORB:

  •  Статические и динамические вызовы методов. CORBA ORB предоставляет возможность либо статически определить вызовы методов прямо во время компиляции, либо находить их динамически, но уже во время работы программы.
  •  Отображение в языки высокого уровня. CORBA ORB позволяет вызывать методы у серверных компонент используя любой из некоторого списка языков высокого уровня — C, C++, SmallTalk, Java и Ada. Совершенно неважно, на каком языке написаны объекты. CORBA отделяет интерфейсы от реализации и предоставляет языково-независимые типы данных, что позволяет осуществлять вызов методов, минуя границы какого-то конкретного языка программирования и конкретной операционной системы.
  •  Само-описывающаяся система. С помощью своих метаданных, CORBA позволяет описывать интерфейс любого сервера, известного системе. Каждая CORBA ORB должна поддерживать Репозитарий Интерфейсов, который хранит необходимую информацию, описывающую синтаксис интерфейсов, поддерживаемых серверами. В своей работе клиенты используют эти метаданные для осуществления вызовов к серверам.
  •  Прозрачность. ORB может выполняться как сам по себе (например, на портативном компьютере), так и в окружении других ORB, с которыми она взаимодействует путем CORBA 2.0 IIOP (Internet Inter-ORB Protocol) протокола. ORB может осуществлять меж-объектное взаимодействие и для одного процесса, и для нескольких процессов, выполняющихся на одной машине, и для процессов, чье выполнение происходит в сети, под разными операционными системами. Реализация этих взаимодействий не затрагивает сами объекты. В общих чертах, при использовании технологии CORBA, разработчик не должен беспокоиться ни о таких вещах как расположение серверов, запуск (активирование) объектов, выравнивание размера переменных в зависимости от платформы и операционной системы, ни и о том, как осуществляется передача сообщений. Решение всех этих задач берет на себя продукт, поддерживающий стандарт CORBA.
  •  Встроенная безопасность. Все свои запросы ORB дополняет некоторой контекстной информацией которая обеспечивает сохранность данных.
  •  Полиморфизм при вызове методов. Как уже говорилось, ORB не просто вызывает удаленный метод — ORB вызывает метод на удаленном объекте. То есть выполнение одних и тех же функций на разных объектах будет приводить к различным действиям, в зависимости от типа объекта.

Выводы. Достоинства и недостатки использования CORBA

Достоинства

  •  Платформенная независимость
  •  Языковая независимость
  •  Динамические вызовы
  •  Динамическое обнаружение объектов
  •  Масштабируемость
  •  CORBA-службы
  •  Широкая индустриальная поддержка

Недостатки

  •  Нет передачи параметров `по значению'
  •  Отсутствует динамическая загрузка компонент-переходников
  •  Нет именования через URL


3.3. Модели распределенных объектов Microsoft COM, DCOM, COM+, .NET

Альтернатива модели CORBA – набор моделей объектов, разработанных для Microsoft Windows.

Промежуточные среды Microsoft Windows

1. Компонентная модель COM (Component Object Model) является наследником средств динамического связывания приложений DDE (Dynamic Data Exchange), имевшихся еще в самых первых версиях Microsoft Windows. Она позволяет разбить приложение, работающее на отдельном ПК, на компоненты, характеризуемые четко описанными интерфейсами.  Таким образом, с помощью этой модели можно организовать распределенную систему в рамках одного ПК. Появилась в Windows 95.

2. Распределенная компонентная модель DCOM (Distributed Component Object Model) - расширение СОМ до уровня сетевых приложений и включает в себя среду распределенных вычислений DCE (Distributed Computing Environment) и механизм удаленного вызова процедур (RPCRemote Procedure Calling).

3. Модель СOM+ - расширение DCOM возможностями распределенной обработки транзакций (MTS). Предназначена для создания систем, распределенных в локальной сети. Основной целью разработки среды COM+ было создание инфраструктуры для разработки распределенных систем автоматизации предприятия. Появилась в Windows 2000.

COM+/MTS = DCOM + MTS – совместное использование DCOM и MTS (Microsoft Transaction Server).

Эти модели предшествовали появлению .Net Framework.

3.3.1 Модель COM (Component Object Model)

Компонент - это хранилище (в виде DLL или EXE файла) для одного или нескольких классов. Все, что знает программа-клиент о классе, это его уникальный идентификатор и один или несколько интерфейсов, которые обеспечивают доступ к реализованным данным классом методам. Допускается реализация компонента и программы-клиента на разных языках (Visual C++, Visual Basic). В реестре системы сохраняется информация о местоположении компонента, который содержит данный класс. Это позволяет системе прозрачно для клиента перенаправлять вызовы методов к нужному компоненту и возвращать результаты.

Таким образом, обеспечивается выполнение двух важных принципов компонентного программирования:

  •  независимость от языка программирования
  •  прозрачность местоположения сервера для клиента.

Определение. Модель СОМ (Component Object Model) или ее еще называют Модель многокомпонентных объектов – это программная модель, которая определяет набор правил, по которым должны строиться компоненты. Только при соблюдении этих правил компоненты обеспечивают корректное и надежное функционирование.

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

Правила определяют стандартный внутренний интерфейс между объектами и методику взаимодействия объектов, а именно – вызов функций и обмен данными между объектами.

Модель СОМ построена по принципу «клиент-сервер».

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

Серверы объектов СОМ 

Каждый объект СОМ реализован внутри некоторого сервера, содержащего код, который реализует методы интерфейсов объекта, а также контролирует данные объекта, пока тот активен. Один сервер может поддерживать (и зачастую поддерживает) более одного объекта некоторого класса и даже поддерживать несколько классов. Рассмотрим три основные типа серверов:

  •  Сервер "в процессе" (in-process): объекты реализуются в динамически подключаемой библиотеке, и, таким образом, исполняются в том же процессе, что и клиент.
  •  Локальный сервер (out-process): объекты реализованы в отдельном процессе, исполняющемся на той же машине, что и клиент.
  •  Удаленный сервер (remote server) объекты реализованы в DLL либо в отдельном процессе, которые расположены на удаленном по отношению к клиенту компьютере.

Возможность создания удаленных серверов поддерживает Распределенная СОМ (DCOM).

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

Таким образом:

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

Технология ActiveX – основные возможности

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

Основные технологии, которые входят сейчас в ActiveX:

  1.  OLE (Object Linking and Embeding) – технология связывания и вставки объектов одного приложения в другое;
  2.  Automation – технология управления вставленными объектами и объектами других приложений;
  3.  ADO (ActiveX Data Object) – технология универсального доступа к разным источникам данных;
  4.  элементы управления ActiveX – технология создания элементов управления ActiveX (собственных компонентов);
  5.  документы ActiveX - технология создания документов, работающих в InternetExplorer, и превращение документов в стандарт документов ActiveX;
  6.  Active Server Pages – технология создания и выполнения сценариев на web-серверах.
  7.  Remote Automation – технология отдаленного управления и ряд других.

Технология OLE – связывание и вставка объектов

Типичный пример этой технологии – вставка и связывание документов разных офисных приложений (Word, Excel, PowerPoint). Поскольку эта возможность реализована в самом офисе, то никакого программирования не требуется.

3.3.2 Распределенная компонентная модель объектов (DCOM)

Определение

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

Она распространяет принципы вызова удаленных процедур (RPC) на объектные приложения COM. В DCOM взаимодействие удаленных объектов базируется на спецификации Distributed Computing Environment Remote Procedure Call (DCE RPC). Среда скрывает от клиента детали сетевого взаимодействия.

Рисунок  Архитектура DCOM. 

DCOM расширяет модель СОМ включением 3-х основных элементов: способа  создания удаленного объекта, протокола  вызова методов этого объекта и механизмов обеспечения безопасного доступа к нему.

DCOM предоставляет несколько вариантов идентификации удаленных машин в зависимости от сетевых протоколов, применяемых для доступа к удаленной системе. DCOM поддерживает доменные имена, используемые TCP/IP, а также адреса IP (Internet Protocol), имена NetBIOS и имена, применяемые NetWare IPX/SPX.

Модель DCOM задает тип и структуру интерфейсов, которые обеспечивают взаимодействие компонентов в распределенной среде. Каждый компонент в модели DCOM должен обладать по крайней мере одним интерфейсом, поддерживающим основные механизмы интерфейсных ссылок. В DCOM реализован механизм уведомления о событиях. Предусмотрены интерфейсы для доступа к метаданным, имеющимся в библиотеке типов Type Library. Интерфейс доступа к библиотеке типов позволяет динамически обнаруживать интерфейсы и обеспечивать взаимодействие компонентов в процессе выполнения.

Интерфейсы компонентов DCOM описываются на языке Interface Definition Language (IDL), разработанном консорциумом Open Software Foundation (OSF).

Среда компонентной разработки, основанная на модели DCOM, поддерживает в настоящее время разработку компонентов на трех языках - Visual Basic, Visual C++ и J++ (язык Java, реализованный Microsoft). Визуальная разработка компонентов поддерживается с помощью страниц свойств компонентов (property sheet) - встроенных редакторов свойств и их агрегированных наборов. Сама среда разработки и исполнения компонентов представляет собой приложение, построенное также на основе модели DCOM, благодаря чему ее можно расширять и настраивать с помощью стандартных механизмов DCOM.

Платформа распределенных компонентов на базе модели DCOM использует ОС Windows NT и выше. В составе служб среды распределенной обработки данных в этой платформе предусмотрены:

- протокол удаленной связи, использующий механизм удаленного вызова процедур RPC, реализованный Microsoft на основе стандартной спецификации RPC DCE (Distributed Computing Environment). Этот протокол обеспечивает связь распределенных компонентов через стандартный механизм посредников (proxy) и заглушек (stub);

- служба каталогов Microsoft Active Directory, которая объединяет систему именования DNS (Domain Name System) и протокол LDAP (Lightweight Directory Access Protocol);

-  служба безопасности, поддерживающая протокол SSL (Secure Sockets Layer), - он обеспечивает защиту данных на базе механизма открытых ключей;

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

-  служба распределенной обработки транзакций в виде сервера Microsoft Transaction Server (MTS), который интегрирует службу транзакций в модель разработки компонентов и предоставляет серверным компонентам транзакционную среду выполнения.

Обеспечение безопасного доступа к удаленному объекту

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

Здесь имеют место две проблемы. Первая заключается в контроле над тем, кто имеет право запускать серверы различных классов на данной удаленной машине — это сфера действия защиты активизации (activation security). Вторая проблема, состоящая в том, чтобы гарантировать контроль прав на вызовы клиентами методов уже исполняющихся объектов, известна как защита вызовов (call security). DCOM предоставляет решения обеих проблем.

Защита активизации 

Параметры реестра машины в точности определяют, кто имеет право запуска серверов на данном компьютере. Более общая установка разрешает или запрещает удаленную активизацию вообще. Если она отключена, ни один удаленный клиент не сможет запускать серверы или подсоединяться к какому-либо объекту на данной машине. Возможно также определение защиты активизации на уровне класса, что позволяет контролировать, какие удаленные клиенты имеют право на запуск сервера некоторого класса. Перечень имеющих разрешение на это содержит список управления доступом (access control list — ACL). И наконец, к классам, для которых не установлена защита активизации на уровне класса, может применяться защита активизации по умолчанию. Как и при защите активизации на уровне класса, защита активизации по умолчанию определяет тех, кто имеет право на запуск сервера в данной системе, с помощью ACL. 

Защита вызовов 

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

  •  аутентификация позволяет удостовериться, что пользователь именно тот, за кого себя выдает. С помощью аутентификации объект достоверно определяет личность клиента. Если поддерживается взаимная аутентификация, то и клиент может быть уверен в том, что сервер является именно тем за кого себя выдает;
  •  авторизация позволяет определить, что клиент имеет пpаво делать. Для принятия подобного решения объект может использовать любую схему;  
  •  целостность данных гарантирует, что принятые по сети данные не были изменены при пересылке. В отсутствие этой службы некто мог бы "выловить" пакет из сети, изменить его и послать первоначальному реципиенту, причем последний не заметил бы подмены;
  •  секретность данных гарантирует, что пересылаемые из сети данные не будут прочитаны при передаче. Обычно для этого используется шифрование данных, что может существенно снизить производительность.

Службы защиты могут обеспечиваться различными механизмами. В связи с большим количеством механизмов, обеспечивающих защиту вызовов, разработчики DCOM столкнулись с проблемой их выбора. Было решено не выбирать какой-то один, а определить общие интерфейсы, способные работать со многими из существующих вариантов. Тем не менее, первая версия DCOM, выпущенная в 1996 году, поддерживает только механизмы защиты Windows NT.

Достоинства и недостатки DCOM

Достоинства 

  •  Независимость от языка
  •  Динамический/статический вызов
  •  Динамическое нахождение объектов
  •  Масштабируемость
  •  Открытый стандарт  

Недостатки 

Сложность реализации

Зависимость от платформы

Нет именования через URL

Нет проверки безопасности на уровне выполнении ActiveX компонент

Microsoft Transaction Server.

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

Он предлагает все стандартные функции монитора транзакций. Важным свойством MTS является то, что свойства транзакционности задаются на уровне контейнера COM. (Кроме того, в Windows входит служба Distributed Transaction Service, отвечающая за координацию распределенных транзакций в базах данных.).

MTS был одной из первых коммерческих систем, комбинировавших поддержку транзакций и компонентов. Приложения, управляемые MTS, представляют из себя наборы COM-компонентов, оформленных в виде динамически подключаемых DLL-библиотек (Dynamic Link Libraries). С технической точки зрения есть несколько служб ОС, контролирующих работу инициированных компонентов COM и отвечающих на исходящие от этих компонентов вызовы. Данные службы обеспечивают автоматическую поддержку транзакций, обеспечение безопасности, образование пулов соединений к БД, поддержку потоков выполнения и управление состоянием объектов.

Сравнение CORBA и DCOM

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

CORBA – претендует на попытку создания стандартной платформы промежуточного уровня для совместной работы приложений разных производителей.

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

По разному реализованы и интерфейсы. CORBA предоставляет стандартный язык IDL, на котором выполняются определения интерфейсов с последующим превращением в тексты программ на выбранном языке программирования. В DCOM используются бинарные интерфейсы (табличные). При таком подходе интерфейсы объектов определяются независимо от ЯП.

3.3.3 Модель COM+

3.3.3.1 Основы COM+

COM+ – промежуточная среда для создания распределенных систем, действующих в локальной сети. Она разрабатывается фирмой Microsoft с конца 90-х годов и впервые появилась в составе Microsoft Windows 2000. Основной целью разработки среды COM+ было создание инфраструктуры для разработки распределенных систем автоматизации предприятия (Enterprise Services). Основные достоинства среды COM+:

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

- Приложение COM+ состоит из набора компонентов и ролей для доступа к ним. Сведения о зарегистрированных приложениях хранятся в каталоге COM+.

- Приложения COM+ бывают двух видов: библиотечные и серверные. Экземпляры компонентов библиотечных приложений выполняются в том же процессе, что и использующий их клиент (in-process), компоненты серверного – в отдельном потоке сервера (out-process), возможно выполняющимся на удаленном компьютере. Только серверные приложения могут использоваться удаленно (remote server) путем регистрации в каталоге COM+ на компьютере клиента посредника приложения COM+. После установки посредников использование удаленных серверных компонентов COM+ не отличается от использования локальных.

На рисунке показана архитектура среды COM+ при использовании серверных приложений. Объекты COM+ являются экземплярами компонентов COM+, зарегистрированных в каталоге. Заглушка на стороне серверного процесса называется в COM+ перехватчиком (interceptor).

Каталог COM+ каждого компьютера содержит список зарегистрированных на компьютере локальных приложений COM+, а также список установленных посредников для связи с приложениями удаленных компьютеров. Каталог устроен иерархически, в виде дерева. Например, узел с описанием приложения COM+ содержит узел со списком входящих в него компонентов COM+ и узел со списком ролей приложений.

Среда COM+ удобна для создания распределенных приложений, но она привязана к платформе Windows, что не всегда приемлемо для корпоративных решений. Важные проблемы, возникающие при построении Windows-приложений, — проблемы надежности, производительности и контроля версий используемых библиотек компонентов (и связанных с ними библиотек DLL).

3.3.3.2 Сервисы COM+

Целью создания промежуточной среды COM+ являлось предоставление компонентам COM+ набора сервисов, облегчающих создание надежной и масштабируемой распределенной системы. Начиная с Windows 2003/XP SP2, часть этих сервисов может быть доступна и без создания компонент COM+, путем использования так называемых сервисов без компонент.

Синхронизация

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

Балансировка нагрузки

COM+ поддерживает динамическую балансировку нагрузки. Для этого необходимо создать кластер COM+ на базе серверной версии операционной системы Microsoft Windows (Windows 2000 Advanced Server и последующих). Кластер COM+ состоит из нескольких серверов и распределяющим между ними запросы маршрутизатором COM+. Для повышения надежности такой системы могут применяться способы быстрой замены маршрутизатора при его выходе из строя на базе Windows Clustering Services. Таким образом, среда COM+ позволяет при наличии достаточных финансовых ресурсов создать хорошо масштабируемую систему без уникальной точки сбоя.

Just-in-time-активация и пул объектов

Среда COM+ поддерживает два вида активации объектов – активация по требованию клиента и активация на время единственного вызова с возможностью использования пула объектов.

Распределенные транзакции

Одним из основных достоинств среды COM+ является поддержка распределенных транзакций на базе координатора распределенных транзакций. Настройки транзакции компонента COM+ влияют на настройки синхронизации и активации.

Отложенные компоненты

Для реализации асинхронного удаленного вызова в среде COM+ существуют так называемые отложенные (ожидающие) компоненты (queued componenets), которые прозрачно используют MSMQ (очереди сообщений). Использование такого компонента подобно асинхронному удаленному вызову.

Рисунок Использование отложенных компонент COM+

1. В начале использования отложенного компонента на стороне клиента создается посредник, называемый протоколистом (recorder), сохраняющий историю вызовов компонента.

2. После завершения использования компонента, если не произошло отката транзакции, протоколист формирует сообщение MSMQ со всеми вызовами компоненты.

3. На стороне сервера сообщение MSMQ ожидается слушателем (listener), который не является COM+ компонентой. При появлении сообщения в очереди он создает специальную COM+ компоненту, называемую помощником слушателя (listener helper), которая считывает сообщение из очереди.

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

Аналогичным образом происходит получение результата вызова удаленной компоненты: на сервере создается протоколист, а на клиенте – слушатель и исполнитель. Однако в этом случае до начала использования удаленной компоненты клиенту следует создать вызываемый объект (call-back object), который будет принимать ответ от сервера через исполнителя, и передать ссылку на такой объект (точнее, на его исполнителя), серверу.

Рисунок Взаимодействие с отложенной компоненты

Выводы по использованию среды Enterprise Services / COM+

Хотя COM+ имеет обширные возможности для создания распределенных систем внутри предприятия, ей свойственны и следующие недостатки.

1. Среда COM+ разработана до .NET Framework, поэтому в среде Enterprise Services существуют ограничения на классы .NET Framework, регистрируемые в качестве обслуживаемых компонент. При использовании компонент Enterprise Services проявляются некоторые особенности работы с ними, являющиеся следствием нетривиального взаимодействия CLR и COM+.

2. Компоненты COM+ не могут использоваться вне доверенной сети, поскольку для их использования должен быть открыт, в частности, доступ к порту RPC (135-ый порт TCP). С данным портом связан большой и, вероятно, еще незаконченный список общеизвестных уязвимостей.

Промежуточная среда COM+ с точки зрения требований к распределенной системе.

1. Открытость. Служба COM+ является внутренней технологией Microsoft и реализована только в операционной системе Windows 2000 и последующих версиях Windows. Для использования обслуживаемой компоненты нужно иметь как минимум доступ к сборке с ее интерфейсом и иметь установленный посредник компоненты COM+. Таким образом, среда Enterprise Services не является открытой.

2. Масштабируемость. Служба COM+ поддерживает балансировку нагрузок путем создания кластера машин на основе Windows Server. Выбор используемого сервера осуществляется только в момент создания объекта клиентом. Среда COM+ поддерживает модель единственного вызова с пулом объектов, что позволяет добиться баланса времени создания удаленного объекта и используемой сервером памяти.

3. Поддержание логической целостности данных. COM+ использует координатор распределенных транзакций из сервера транзакций Microsoft (MTS) и позволяет создавать менеджеры управления ресурсами.

4. Устойчивость. Посредники приложения COM+ связывают клиентский компьютер с именем компьютера (DNS или NETBIOS), на котором развернуто приложение COM+.

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

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

6. Безопасность. COM+ позволяет использовать встроенные механизмы безопасности Microsoft Windows.

Можно сделать вывод, что хотя промежуточная среда EnterpriseServices/COM+ предоставляет обширный набор сервисов для компонент распределенной системы, но ее использование ограничено взаимодействием компонент внутри локальной или виртуальной частной сети, построенной на базе Microsoft Windows в пределах одного предприятия.


Тема 4 Разработка распределенных приложений на платформе Microsoft.Net Framework

План

4.1. Основы платформы Microsoft.Net Framework

4.2. Введение в среду Common Language Runtime

4.3. Преимущества платформы MS.Net

4.4. Поддержка средств распределенной разработки

4.5. Сервисы и интерфейс программной компоненты

4.6 Среда Microsoft Message Queuing (MSMQ)

4.7. Net Remoting

4.1. Основы платформы .Net Framework

Одной из задач, стоящих перед разработчиками Microsoft, создающими так называемую общеязыковую инфраструктуру (Common Language Infrastructure, CLI), так же известную как .NET, была наиболее полная поддержка средств разработки распределенных систем. Поэтому в платформе разработки приложений Microsoft.NET Framework имеется встроенная поддержка четырех взаимосвязанных технологий, предназначенных для использования в распределенных системах:

очередей сообщений (messaging queues),

объектов COM+,

веб-сервисов (web services).

объектов .NET Remoting,

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

Под платформой Microsoft.NET Framework следует понимать интегрированную систему (инфраструктуру) средств разработки, развертывания и выполнения сложных (как правило, распределенных) программных систем.

Платформа .NET состоит из нескольких основных компонентов (см. рис. 4.1):

Рис. 4.1 Платформа Microsoft.NET

  1. − операционные системы корпорации Microsoft (Windows 2000/XP/ME/CE), представляющие собой базовый уровень платформы MS.Net,
  2. - серверы MS.Net (.Net Enterprise Servers) являются программными продуктами корпорации Microsoft, использование которых позволяет снизить сложность разработки сложных программных систем. В числе готовых для применения серверы Application Center 2000, Exchange Server 2000, SQL Server и др.,
  3. − сервисы MS.Net (.Net Building Block Services) представляют собой готовые "строительные блоки" сложных программных систем, которые могут быть использованы через Интернет как сервисные услуги. Набор таких сервисов MS.Net планируется последовательно расширять. Примером имеющегося сервиса платформы MS.Net является Microsoft Passport, позволяющий установить единое имя пользователя и пароль на всех сайтах, поддерживающих аутенфикацию через Passport,
  4. − интегрированная среда разработки приложений Visual Studio.NET (VS.Net) – верхний уровень MS.Net - обеспечивает возможность создания сложного ПО на основе платформы и продолжает в этом плане ряд разрабатываемых корпорацией Microsoft средств разработки профессионального программного обеспечения.

Подсистема MS.NET Framework является ядром платформы MS.Net, обеспечивая возможность построения и исполнения .Net приложений.

Рис. 4.2 Архитектура MS.NET Framework

В состав MS.NET Framework входит: общеязыковая среда выполнения (Common Language Runtime или CLR) и библиотеки классов подсистемы MS.NET Framework. По своему функциональному назначению в составе библиотек классов могут быть выделены:

− набор базовых классов, обеспечивающих, например, работу со строками, ввод-вывод данных, многопоточность и т.п.,

− набор классов для работы с данными, предоставляющих возможность использования SQL-запросов, ADO.Net и обработки XML данных,

− набор классов Windows Forms, позволяющих создавать обычные Windows-приложения, в которых используются стандартные элементы управления Windows,

− набор классов Web Forms, обеспечивающих возможность быстрой разработки Web-приложений, в которых используется стандартный графический интерфейс пользователя,

− набор классов Web Services, поддерживающих создание распределенных компонентов-сервисов, доступ к которым может быть организован через Интернет.

Базовый уровень подсистемы MS.NET Framework составляет общеязыковая среда выполнения (Common Language Runtime или CLR).

4.2 Введение в среду Common Language Runtime

Как следует из самого названия, общеязыковая среда выполнения CLR обеспечивает исполнение программного кода и является в этом плане основой платформы MS.Net. Среда CLR активизирует исполняемый код, выполняет для него проверку безопасности, располагает этот код в памяти и исполняет его. Важной частью работы среды CLR является управление свободной памятью, автоматически обеспечивая использование освобождающейся при работе программ памяти (сборку мусора).

Для представления общей схемы функционирования среды CLR дадим ряд важных для платформы MS.Net понятий и определений:

• Для обеспечения возможности многоязыковой разработки ПО программный код, получаемого после компиляции программы на одном из алгоритмических языков платформы MS.Net, представляется на специально разработанным в корпорации Microsoft общем промежуточном языке (Common Intermediate Language или CIL). Этот язык, с одной стороны, достаточно близок к машинно-зависимым языкам – ассемблерам, с другой стороны, CIL обеспечивает некоторый более высокий уровень представления различных компьютерных платформ. Как результат, программа на языке CIL остается платформенно-независимой, однако требует некоторой дополнительной настройки (компиляции) перед началом своего выполнения,

• Программные файлы на языке CIL, получаемые после компиляции программ на алгоритмических языках платформы MS.Net, называются сборками (assembly), другое более технические наименование сборок - переносимые исполняемые файлы (Portable Executable или PE). Сборки являются основными структурными элементами (.Net компонентами) разрабатываемого в рамках .Net программного обеспечения и, относятся, тем самым, к числу наиболее важных понятий платформы MS.Net. В конструктивном плане, сборки являются файлами с расширениями exe или dll и состоят из непосредственно программного кода на языке CIL и дополнительных служебных данных, именуемых в MS.Net метаданными (в составе метаданных необходимая информация о сборке – сведения о типах, данные о версии, ссылки на внешние сборки и т.п.),

• Как уже отмечалось выше, сборки перед своим исполнением должны пройти определенную настройку для работы в условиях конкретной выбранной платформы – для выполнения таких настроек в составе среды CLR имеется ряд JIT-компиляторов (Just-In-Time compilers), вызываемых для перевода программного кода на промежуточном языке (CIL-кода) в машинный (native) код платформы исполнения.

Рис. 4.3. Среда CLR: общая схема исполнения сборок

С учетом введенных понятий представим общую схему исполнения сборок в среде CLR (рис. 4.3):

− При запуске сборки загрузчик распознает .Net приложение и передает управление среде CLR, далее загрузчик классов находит и загружает класс, в котором содержится точка начала работы сборки (обычно функция Main), затем CLR передает управление сборке,

  1. − Загрузчик классов выполняется каждый раз при первом обращении к необходимым для выполнения сборки классам. Загрузчик находит нужный класс, размещает информацию о типах класса в кэше и загружает класс для выполнения (при этом в методах загружаемого класса делается отметка, что они не являются еще готовыми для выполнения, поскольку не прошли через JIT-компиляцию),
  2. − Верификатор является частью JIT-компилятора и отвечает за проверку корректности CIL-кода и метаданных. Подобный контроль повышает надежность работы программ, с другой стороны, верификация может и не осуществляться (например, для доверенного кода),
  3. − JIT-компиляторы вызываются при обращении к CIL-коду, который ранее при работе программы еще не компилировался. В результате компиляции получается машинный код, оптимизированный для выбранной платформы, для откомпилированного метода устанавливается адрес полученного машинного кода и управление передается исполняемой сборке. Как результат, компиляция методов классов осуществляется только в момент первого к ним обращения (и, тем самым, не используемые методы классов останутся не откомпилированными). Подобная схема компиляции по мере необходимости может существенно снизить размеры порождаемого программного кода и сократить время подготовки сборки для выполнения, вместе с этим, в среде CLR может быть выполнена и полная компиляция сборки перед началом исполнения (pre-JITing),
  4. − Непосредственное выполнение машинного кода также происходит при активном взаимодействии со средой CLR. Функции среды выполнения (см. рис. 4.3) состоят в управлении свободной памятью, обработке исключений, поддержке безопасности и др.

Языки программирования: С++, Managed C++ (расширение для MS.NET), C# (специально для MS.NET), VBasic.Net, Java#

Примеры программ для платформы MS.Net

Первая программа на управляемом C++

Начнем с простой программы, написанной на управляемом C++ (Managed C++ - расширение языка С++ для платформы Microsoft.NET):

// Первая программа на Managed C++

#using <mscorlib.dll>

using namespace System;

void main()

{

Console::WriteLine(”C++ Hello, World!”);

}

Как можно увидеть, это практически обычная программа на C++ - отличие состоит лишь в том, что вместо директивы препроцессору #include используется конструкция #using. С помощью директивы #using можно подключать модули, написанные на любом языке программирования, имеющимся в .NET. #using подключает модуль, а затем с помощью using импортируется нужное пространство имен из этого модуля. Например, пространство имен System, содержащее некоторые базовые системные классы, такие, как Console.

В данной программе методе main() содержит единственный оператор, который является вызовом статического метода WriteLine() класса Console, предназначенным для вывода переданной строки на устройство вывода.

Затем программу необходимо скомпилировать. Сделать это можно как с помощью среды разработки Visual Studio .NET, так и с помощью компилятора командной строки:

cl hello.cpp /CLR /link /entry:main

После выполнения компилятор создаст файл hello.exe, и, если запустить его, CLR загрузит, проверит и выполнит его.

Первая программа на C#

Новый язык программирования C# разработан компанией Microsoft с учетом основных положений технологий Microsoft.Net и вбирает в себя положительный опыт практического использования языков C++ и Java. После своего создания язык C# прошел серьезную проверку, поскольку Microsoft использовал C# для разработки большей части базовых классов и утилит платформы MS.Net..

Рассмотрим пример простой программы на языке C#

// Первая программа на C#

using System;

class MainApp

{

public static void Main()

{

Console.WriteLine(“C# Hello, World!”);

}

}

Код C# отличается от С++ тем, что заголовочных файлов нет совсем – и определение классов и их реализация располагаются в одном файле с расширением .cs. Директива using аналогична по смыслу той же директиве в Managed C++, но при этом нет необходимости указывать файл, где содержится такое пространство имен.

Компиляция программы на C# выполняется при помощи команды:

csc hello.cs

Первая программа на VB.Net

Наконец, приведем примерHello, World на Visual Basic .NET 

Rem Первая программа на VB.Net

Imports System

Public Module modmain

Sub Main()

Console.WriteLine(“VB Hello, World!”)

End Sub

End Module

Как можно увидеть из примера, язык Visual Basic немного изменился и стал похож на C#, сохранив при том все свои отличительные черты (практически каждая строка программы может быть перетранслирована в аналогичную строку на C#).

Получение исполняемого PE-файла может быть выполнено при помощи команды:

vbc /t:exe /out:hello.exe hello.vb

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

4.3 Преимущества платформы MS.Net

В ходе последовательного развития новых методов, средств и подходов разработки сложного обеспечения регулярно возникали моменты обобщения и интеграции, когда появлялись решения, органично вбирающие в себя последние достижения в области науки и практики программирования. Эти знаковые решения (заслуженно иногда называемые революционными открытиями) приводили к подъему мира программирования на качественно иной уровень состояния дел. Так происходило при разработке языков программирования Pascal и C, создании операционных систем Unix и Windows, отработке принципов объектно-ориентированного программирования и их реализации в языке программирования C++, применении интегрированных и визуальных средств разработки, появлении Интернет и Java, и т.д. Так произошло и при создании новой платформы Microsoft.Net для разработки, развертывания и выполнения сложного программного обеспечения.

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

Следует отметить и ряд других ключевых моментов, характеризующих значимость появления платформы Microsoft.Net:

  1. Современные средства разработки - платформа Microsoft.Net включает в себя как готовые компоненты для построения ПО, так и интегрированную среду разработки, обеспечивая возможность многоязыковой разработки программных систем с использованием разных языков программирования (C#, C++, VBasic.Net, Java# и др.). Как результат, разработчик программ уже не ограничивается выбором одного какого-либо языка программирования, а может варьировать средства разработки с учетом собственного опыта и свойств разрабатываемых программ даже в пределах одной программной системы. Следует отметить также, многие общие части (типы данных, обработка исключений, библиотеки) разных языков программирования являются одинаковыми;
  2. Компонентное представление ПО – Microsoft.Net развивает существующие подходы к основному способу снижения сложности ПО - компонентному представлению программных систем - предлагая более простой, удобный и надежный метод формирования программных компонент;
  3. Распределенные вычисления – использование платформы Microsoft.Net в значительной степени снижает сложность современной формы разработки ПО в виде распределенных программных систем или клиент-серверных приложений;
  4. Интернет технологии - платформа Microsoft.Net содержит большинство существующих Интернет технологий, обеспечивая возможность быстрой разработки как обычных Web-приложений, так и Web-сервисов, выступающих как доступные через Интернет "строительные блоки" современного сервис-ориентированного программного обеспечения и др.

4.4 Поддержка средств распределенной разработки

В настоящий момент в Microsoft.NET Framework Class Library присутствует поддержка четырех промежуточных сред для построения распределенных систем:

– Среда Microsoft Message Queuing (MSMQ) поддерживает обмен сообщениями между программными компонентами на основе очередей.

– Среда Microsoft Enterprise Services основана на модели COM+, которая позволяет использовать удаленные объекты и распределенные транзакции в локальной сети.

– Среда ASP .NET Web Services позволяет организовать удаленный вызов на основе общепринятых стандартов, базирующихся на языке XML.

- Среда .NET Remoting была разработана как универсальная промежуточная среда для использования удаленных объектов.

В настоящее время ведутся работы по интеграции этих сред в единую универсальную среду распределенной разработки. Так, в версии .NET Framework 3.0 предполагается ввести технологию WCF (Windows Communication Foundation), объединяющую все упомянутые технологии построения распределенных систем. Кроме указанных технологий, приложения на .NET Framework могут использовать, например, удаленные вызовы на основе стандарта XML-RPC при подключении дополнительных библиотек.

4.5 Сервисы и интерфейс программной компоненты

Для работы с сервисами программной компоненты обращающийся к ним клиент должен иметь полное представление об интерфейсе используемой компоненты. В роли сервиса, предоставляемого программной компонентой, созданной с помощью .NET Framework, выступает одно из следующих понятий:

– методы активируемого сервером объекта;

– активируемый клиентом объект вместе со своими полями, свойствами и методами;

– очередь с сообщениями-запросами, которые считываются программной компонентой.

Адрес сервиса зависит от промежуточной среды и является совокупностью сетевого адреса компоненты и некоторого публичного имени сервиса. Сетевой адрес программной компоненты основан на имени ее компьютера для систем удаленного вызова или на адресе менеджера очереди для систем обмена сообщениями. Данный адрес является адресом нижестоящего протокола, на котором основана данная промежуточная среда. В роли него может выступать HTTP, TCP, NetBIOS, или протокол нижестоящей промежуточной среды. Второй составляющей адреса сервиса является идентификатор сервиса. В роли него может выступать идентификатор активируемого класса для сред удаленного вызова или же имя очереди сообщений, из которой сервис считывает сообщения-запросы.

Если компонента системы передачи сообщений посылает сообщения-ответы клиенту, то можно считать, что сервис такой компоненты имеет два адреса – один для очереди запросов и второй для очереди ответов (имя очереди ответов может быть задано и в сообщении-запросе).

Таким образом, каждый сервис программной компоненты характеризуется тремя сущностями:

– полным адресом сервиса;

– единственной спецификацией принимаемых сервисом сообщений (запросов);

– единственной спецификацией принимаемых от сервиса сообщений (ответов).

Совокупность спецификаций всех сервисов программной компоненты образует ее интерфейс.

Рис. 4.4. Интерфейс компоненты распределенной системы

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

– язык передаваемых в распределенной системе сообщений, обычно описывающий результат сериализации объектов;

– язык описания спецификаций сообщений, определяющий корректные сообщения для сервисов компоненты;

– язык описания интерфейса компоненты, определяющий набор ее сервисов.

Языки описания интерфейса и спецификаций сообщений часто представлены на практике одним языком.

Примечания

1. Процесс преобразования параметров для передачи их между процессами (или доменами приложения в случае использования .NET) при удаленном вызове называется маршализацией (marshaling).

2. Преобразование экземпляра какого-либо типа данных в пригодный для передачи за границы вызывающего процесса набор байт называется сериализацией.

3. Десериализация – процедура, обратная сериализации – заключается в создании копии сериализованного объекта на основе полученного набора байт.

Такой подход к передаче объекта между процессами путем создания его копий называется маршализацией по значению (marshal by value), в отличие от маршализации по ссылке.

Для систем удаленного вызова спецификацией интерфейса может являться описание класса .NET.

Таким образом, метаданные из сборок с описанием интерфейса или класса удаленного объекта и классами параметров его методов полностью определяют интерфейс программной компоненты, созданной при помощи .NET Framework. Однако такой подход часто неудобен, поскольку не только уменьшает открытость системы, привязывая описание интерфейса программной компоненты к используемому для ее создания средству разработки, но и требует предоставления в общем случае сборок с классами компоненты клиенту. Поэтому существует потребность в общепринятых и независимых от средств разработки программных компонент языках описания интерфейса компоненты.

В качестве такого языка в РС все чаще применяется XML, в частности, такие его реализации как XSD, SOAP, WSDL.

Поскольку протокол HTTP был как наиболее распространенным, так и повсеместно разрешенным в межсетевых экранах протоколом, то он был выбран в качестве стандартного транспортного протокола для создания гетерогенных промежуточных сред. Поэтому использующая SOAP и WSDL промежуточная среда получила названия веб-служб (web services). Она использует два дополнительных языка – язык описания сообщения SOAP (пространство имен SOAP версии 1.1 – http://schemas.xmlsoap.org/soap/envelope/, версии 1.2 – http://schemas.xmlsoap.org/wsdl/soap12/) и язык описания сервисов и интерфейсов WSDL (пространство имен http://schemas.xmlsoap.org/wsdl/).

Рекомендация SOAP изначально разрабатывалась как спецификация для удаленного вызова методов и расшифровывалась как Simple Object Access Protocol. Сообщение SOAP представляет собой XML-документ, называемый конвертом или пакетом (envelope), содержащий заголовки с метаинформацией в элементе soap:Header и тело сообщения в элементе soap:Body. В заголовках пакета содержится дополнительная информация, которая может использоваться промежуточной средой.

В качестве примера рассмотрим простейшие сообщения SOAP версии 1.2 для сервиса, складывающего два числа. Сообщение-запрос использует пространство имен http://summa.test/webservices, которое описано в интерфейсе компоненты. В элементе message содержатся сами складываемые числа.

<?xml version="1.0" encoding="utf-8"?>

<soap12:Envelope xmlns:soap12="http://www.w3.org/2003/05/soap-envelope">

<soap12:Body>

<Add xmlns="http://summa.test/webservices">

   <message>

       <a>1</a>

       <b>2</b>

   </message>

</Add>

</soap12:Body>

</soap12:Envelope>

Сообщение с ответом программной компоненты.

<?xml version="1.0" encoding="utf-8"?>

<soap12:Envelope xmlns:soap12="http://www.w3.org/2003/05/soap-envelope">

<soap12:Body>

 <AddResponse xmlns="http://summa.test/webservices">

      <AddResult>3</AddResult>

 </AddResponse>

</soap12:Body>

</soap12:Envelope>

WSDL: описание интерфейса программной компоненты

Для описания интерфейса программной компоненты был разработан язык WSDL (Web Service Definition Language). Описание на языке WSDL включает в себя следующие семь составляющих.

1. Описание типов передаваемых данных. При использовании кодирования SOAP-Document оно состоит из схемы XML, определяющей корректные сообщения, получаемые программной компонентой в теле пакета SOAP.

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

3. Описание операций (сервисов программной компоненты), с каждой из которых связывается входящее и исходящее сообщение.

4. Описание типов портов (идентификаторов программных компонент), с каждым из которых связывается некоторый набор операций.

5. Описание привязок (binding), связывающие типы портов и их сообщений с определенным типом кодирования тела пакета, а также с версией протокола SOAP.

6. Описание портов, связывающие типы портов и соответствующие им привязки с конкретными URL.

7. Общее описание службы (интерфейса программной компоненты) как совокупности портов.

Далее рассмотрено описание на языке WSDL интерфейса компоненты, которое содержит два сервиса – сложение двух чисел и сложение последовательности чисел. В корневом элементе указаны все используемые пространства имен, включая пространство протокола SOAP 1.2 – http://schemas.xmlsoap.org/wsdl/soap12/.

Начало описания XML-документа

<?xml version="1.0" encoding="utf-8"?>

<wsdl:definitions

    xmlns:tns="http://summa.test/webservices"

    xmlns:s="http://www.w3.org/2001/XMLSchema"

    xmlns:soap12="http://schemas.xmlsoap.org/wsdl/soap12/"

    targetNamespace="http://summa.test/webservices"

    xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/">

В элементе wsdl:types описываются все типы данных. Тип Add будет связан со входящим сообщением сервиса сложения двух чисел, а тип AddResponse – с его исходящим сообщением.

<wsdl:types>

   <s:schema elementFormDefault="qualified"

          targetNamespace="http://summa.test/webservices">

     <s:element name="Add">

        <s:complexType>

            <s:sequence>

                 <s:element minOccurs="1" maxOccurs="1" name="message"

                          type="tns:AddMessage" />

            </s:sequence>

            </s:complexType>

      </s:element>

      <s:complexType name="AddMessage">

          <s:sequence>

                <s:element minOccurs="1" maxOccurs="1" name="a" type="s:int" />

                <s:element minOccurs="1" maxOccurs="1" name="b" type="s:int" />

           </s:sequence>

          </s:complexType>

      <s:element name="AddResponse">

          <s:complexType>

             <s:sequence>

                   <s:element minOccurs="1" maxOccurs="1" name="AddResult" type="s:int" />

             </s:sequence>

          </s:complexType>

                        </s:element>

Типы SumList и SumListResponse предназначены для сообщений сервиса сложения списка чисел.

<s:element name="SumList">

  <s:complexType>

     <s:sequence>

         <s:element minOccurs="0" maxOccurs="1" name="list"

                  type="tns:ArrayOfInt" />

         </s:sequence>

  </s:complexType>

</s:element>

<s:complexType name="ArrayOfInt">

<s:sequence>

    <s:element minOccurs="0" maxOccurs="unbounded" name="int" type="s:int" />

</s:sequence>

</s:complexType>

   <s:element name="SumListResponse">

    <s:complexType>

        <s:sequence>

            <s:element minOccurs="1" maxOccurs="1" name="SumListResult"

                  type="s:int" />

        </s:sequence>

    </s:complexType>

   </s:element>

</s:schema>

</wsdl:types>

В элементах wsdl:message типы данных связываются с идентификаторами сообщений.

<wsdl:message name="AddSoapIn">

      <wsdl:part name="parameters" element="tns:Add" />

</wsdl:message>

       <wsdl:message name="AddSoapOut">

         <wsdl:part name="parameters" element="tns:AddResponse" />

</wsdl:message>

       <wsdl:message name="SumListSoapIn">

       <wsdl:part name="parameters" element="tns:SumList" />

</wsdl:message>

       <wsdl:message name="SumListSoapOut">

       <wsdl:part name="parameters" element="tns:SumListResponse" />

</wsdl:message>

В элементе wsdl:portType описываются абстрактные операции и используемые ими сообщения.

<wsdl:portType name="MathServiceSoap">

  <wsdl:operation name="Add">

      <wsdl:documentation xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/">

              Операция Add складывает два числа

      </wsdl:documentation>

      <wsdl:input message="tns:AddSoapIn" />

      <wsdl:output message="tns:AddSoapOut" />

  </wsdl:operation>

  <wsdl:operation name="SumList">

           <wsdl:documentation xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/">

                Операция SumList складывает несколько чисел

           </wsdl:documentation>

          <wsdl:input message="tns:SumListSoapIn" />

          <wsdl:output message="tns:SumListSoapOut" />

  </wsdl:operation>

</wsdl:portType>

В элементе wsdl:binding операции связываются с транспортным протоколом (HTTP),

версией протокола SOAP (1.2) и типом кодирования тела пакета (SOAP-Document).

<wsdl:binding name="MathServiceSoap12" type="tns:MathServiceSoap">

     <soap12:binding transport="http://schemas.xmlsoap.org/soap/http" />

        <wsdl:operation name="Add">

      <soap12:operation soapAction="http://summa.test/webservices/Add"

                style="document" />

      <wsdl:input>

           <soap12:body use="literal" />

      </wsdl:input>

      <wsdl:output>

           <soap12:body use="literal" />

      </wsdl:output>

      </wsdl:operation>

              <wsdl:operation name="SumList">

               <soap12:operation soapAction="http://summa.test/webservices/SumList"

                        style="document" />

               <wsdl:input>

                   <soap12:body use="literal" />

             </wsdl:input>

             <wsdl:output>

                   <soap12:body use="literal" />

              </wsdl:output>

             </wsdl:operation>

      </wsdl:binding>

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

<wsdl:service name="MathService">

       <wsdl:port name="MathServiceSoap12" binding="tns:MathServiceSoap12">

                <soap12:address location="http://summa.test/webservices/summa.asmx" />

       </wsdl:port>

</wsdl:service>

</wsdl:definitions>

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

Для создания открытой распределенной системы необходимо использование общепринятых языков описания интерфейса программной компоненты. В настоящий момент существует ряд апробированных на практике стандартов для передачи данных в гетерогенных распределенных системах: XML, XSD, SOAP и WSDL. Их использование позволяет создавать системы, не привязанные жестко к какому-либо средству разработки программ или транспортному протоколу.

4.6 Среда Microsoft Message Queuing (MSMQ)

Промежуточная среда MSMQ – разработка Microsoft для асинхронной передачи сообщений внутри локальной сети, впервые появившаяся в составе операционной системы Windows NT. В настоящее время последней является версия MSMQ 3.0, включенная в Windows XP PE и 2003 Server, достаточно актуальна так же версия 2.0, включенная в состав операционной системы Windows 2000.

Служба MSMQ позволяет произвольному набору приложений добавлять сообщения в некоторую очередь, и произвольному же набору – читать сообщения из очереди.

Приложению, использующему MSMQ, доступны следующие основные операции:

– добавить сообщение в очередь;

– извлечь первое сообщение из очереди;

– установить обработчик, вызываемый при появлении сообщения.

Структура сообщения определяется приложением, и может быть произвольной, с ограничением на размер одного сообщения (2Мб для MSMQ 2.0).

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

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

– сообщение доставляется сразу в указанную отправителем очередь (прямая доставка);

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

– MSMQ определяет, что сообщение требуется разослать в несколько очередей (возможность поддерживается начиная с MSMQ 3.0).

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

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

Рис. 4.4.  Системы очередей сообщений

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

Рис. 4.5. Пересылка сообщения в промежуточной среде MSMQ

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

Благодаря службе маршрутизации сообщений возможно создание моста между MSMQ и аналогичной технологией IBM – IBM Websphere MQ (ранее MQSeries).

Websphere MQ может использоваться и напрямую программами .NET Framework, однако обычно это менее удобно, чем использование MSMQ, и может быть связано с дополнительными затратами – служба MSMQ уже входит в большинство систем семейства Windows. Использование моста MSMQ-MQSeries позволяет создавать гетерогенные распределенные системы на основе обмена сообщениями, поскольку технология IBM MQ является изначально межплатформенной.

Приложение может вести поиск нужной ему очереди по ряду критериев. Это возможно при использовании механизма общих очередей в Microsoft Message Queuing, что требует развертывания Microsoft Active Directory.

Инфраструктура, необходимая для использования MSMQ

Служба MSMQ может работать как в составе домена Active Directory, так и при отсутствии такого домена, но во втором случае невозможно использовать ряд возможностей MSMQ, а именно:

– не поддерживается шифрование передаваемых сообщений;

– не поддерживаются общие очереди и механизмы их обнаружения;

– не поддерживается маршрутизация сообщений и групповая рассылка сообщений.

В MSMQ существуют два вида очередей – общие (public) и частные (private). Как частные, так и общие очереди могут либо использовать, либо не использовать транзакции, что задается при создании очереди и не может быть изменено в дальнейшем.

Информация об общих очередях публикуется в службе каталогов Active Directory. Путь к общей очереди имеет вид ComputerName\QueueName, возможна также запись пути в

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

Возможна также проверка приложением наличия общей очереди на удаленном компьютере и ее создание. Для использования общих очередей требуется развертывание MSMQ в рамках домена Active Directory.

Частные очереди доступны как при наличии домена, так и при его отсутствии. Путь к такой очереди имеет вид ComputerName\Private$\QueueName или .\Private$\QueueName для локального компьютера. Приложение, не имеет возможности ни создать, ни проверить наличие частной очереди на удаленном компьютере при использовании средств библиотеки FCL.

Применение службы сообщений MSMQ в распределенных системах

Рассмотрим возможности, предоставляемые службой MSMQ как промежуточным программным обеспечением с точки зрения требований, предъявляемых к распределенной системе.

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

2. Безопасность. MSMQ поддерживает обычные для Windows NT списки управлением доступа (ACL) для каждой очереди, а при наличии домена AD – прозрачное шифрование сообщений. Таким образом, система, использующая MSMQ, может являться безопасной при развертывании в пределах домена Active Directory.

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

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

4. Обеспечение целостности данных. MSMQ поддерживает внутренние транзакции, распределенные транзакции среды COM+ и транзакции из System.Transactions.

Внутренние транзакции гарантируют, что некоторая последовательность операций компоненты с очередями (например, получение сообщение и отправка ответа на него) будет либо выполнена полностью, либо не выполнена вообще. Транзакции среды COM+ и пространства имен System.Transactions используют координатор распределенных транзакций (MS DTC). При их использовании в последовательность операций, образующих транзакцию, кроме действий с очередями сообщений могут входить операции с любыми службами, поддерживающие распределенные транзакции. Кроме использования транзакций, для повышения надежности в MSMQ следует использовать механизм восстанавливаемых сообщений, который повышает вероятность того, что после принятия службой MSMQ сообщение не будет потеряно при аварийном отключении питания. 

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

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

– необходимость явного использования очередей распределенным приложением;

- сложность реализации синхронного обмена.

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

В первом случае MSMQ предпочтительнее технологий удаленного вызова в одном из в следующих случаев:

– обеим взаимодействующим компонентам известен только посредник (компьютер с используемой очередью сообщений);

– заявки обрабатываются несколькими компьютерами параллельно;

– вызывающая компонента не знает внешний интерфейс удаленного вызова вызываемой компоненты.

Использование очередей сообщений MSMQ в .NET Framework

Для работы с очередями сообщений используются классы из пространства имен System.Messaging. Класс System.Messaging.MessageQueue содержит три группы методов.

1. Статические методы для администрирования очередей: Create, Delete, Exists, Purge.

2. Методы поиска общих очередей: GetPublicQueues, GetPublicQueuesByLabel и другие. При их использовании можно создать приложение, которое переключается между несколькими менеджерами очередей в пределах Active Directory, если один из них выходит из строя.

3. Методы для работы с сообщениями (Send, Receive, Peek и другие), в том числе позволяющие использовать обработчик на завершение операции (BeginPeek, BeginReceive).

При применении классов из System.Messaging возможно три варианта работы с очередями сообщений:

– работа с очередями, не использующими транзакции;

– работа с очередями, поддерживающими транзакции, при использовании внутренних транзакций MSMQ;

– работа с очередями, поддерживающими транзакции, при использовании распределенных транзакций COM+.

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

Пример.

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

using System;

using System.Messaging;

using System.Collections.Generic;

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

namespace Seva.Msmq

{

// типы очередей

enum QueueType {NonTransactional, Transactional};

// типы классов форматирования

enum QueueFormatter {Binary, Xml};

// делегат общего вида для обработки сервером сообщений клиента

delegate AnswerType ProcessRequestEventHandler

<RequestType, AnswerType>(Object sender, RequestType request,

MessageQueue queueResponse);

// делегат общего вида для обработки ответов сервера клиентом

delegate void ProcessAnswerEventHandler<RequestType, AnswerType>

(Object sender, RequestType request, AnswerType answer);

Абстрактный класс MSMQUser, наследуемый классами MSMQServer и MSMQClient.

public abstract class MsmqUser

{

// использование восстанавливаемых сообщений

private bool recoverable = false;

public bool Recoverable

{

get {

return recoverable;

}

set {

recoverable = value;

}

}

// объекты форматирования для посылки приема сообщений

protected IMessageFormatter requestFormatter;

protected IMessageFormatter answerFormatter;

//

public MsmqUser(QueueFormatter formatterType)

{

if (formatterType == QueueFormatter.Xml)

{

requestFormatter = new XmlMessageFormatter(

new Type[]{typeof(RequestType)});

answerFormatter = new XmlMessageFormatter(

new Type[]{typeof(AnswerType)});

}

if (formatterType == QueueFormatter.Binary)

{

requestFormatter = new BinaryMessageFormatter();

answerFormatter = new BinaryMessageFormatter();

}

}

}

Класс общего вида, посылающий через MSMQ запросы и получающий ответы на них.

class MsmqClient<RequestType, AnswerType> :

MsmqUser<RequestType, AnswerType>, IDisposable

{

// очереди для отсылки запросов и приема ответов

private MessageQueue queueSend;

private MessageQueue queueReceive;

// список необслуженных запросов

private Dictionary<String, RequestType> messages;

public Dictionary<String, RequestType> Messages

{

get { return messages;}

}

// событие, вызываемое при приеме ответа

public event ProcessAnswerEventHandler<RequestType, AnswerType>

ProcessAnswer;

Конструктор, получающий имена очередей для посылки и приема сообщений.

public MsmqClient(String queueSendName, String queueReceiveName,

QueueFormatter formatterType): base(formatterType)

{

// список отправленных сообщений без ответов

messages = new Dictionary<String,RequestType>();

// создание очереди для посылки запросов, если она не существует

queueSend = MsmqTools.CreateQueue(queueSendName,

QueueType.Transactional);

// создание очереди для приема ответов, если она нужна

if (queueReceiveName != null)

{

queueReceive = MsmqTools.CreateQueue(queueReceiveName);

queueReceive.Formatter = answerFormatter;

// считывать из очереди свойство CorrelationId

queueReceive.MessageReadPropertyFilter.CorrelationId = true;

}

else

{

queueReceive = null;

}

}

В методе Dispose происходит закрытие используемых очередей.

public void Dispose()

{

queueSend.Close();

queueSend.Dispose();

if (queueReceive != null)

{

queueReceive.Close();

queueReceive.Dispose();

}

}

Функции BeginReceive и EndReceive начинают и прекращают прием ответов сервера,

изменяя обработчик события PeekComplete очереди ответов.

public void BeginReceive()

{

// установить обработчик на событие, возникающее при появлении

// сообщения в очереди

queueReceive.PeekCompleted += OnPeek;

// начать отслеживание поступления сообщения в очередь

queueReceive.BeginPeek();

}

// прекратить прием ответов сервера

public void EndReceive()

{

// отключить обработчик

queueReceive.PeekCompleted -= OnPeek;

}

Функция Send посылает в исходящую очередь запрос общего типа для его обработки сервером. Для ответа на сообщение серверу следует использовать очередь, указанную в поле ResponseQueue посылаемого сообщения.

public void Send(RequestType request)

{

// создание нового сообщения

Message message = new Message(request, requestFormatter);

message.ResponseQueue = queueReceive;

// использование восстаналиваемых сообщений

message.Recoverable = Recoverable;

// послать сообщение; поскольку транзакция состоит из

// единственной операции, вместо объекта-транзакции используется

// значение MessageQueueTransactionType.Single

queueSend.Send(message, MessageQueueTransactionType.Single);

// поле message.Id устанавливается после посылки сообщения;

// идентификатор сообщения связывается c отосланным запросом

// в списке необслуженных запросов

messages.Add(message.Id, request);

}

Обработчик события очереди PeekComplete использует внутренние транзакции MSMQ.

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

public void OnPeek(Object source, PeekCompletedEventArgs asyncResult)

{

// создание внутренней транзакции MSMQ

MessageQueueTransaction transaction = new MessageQueueTransaction();

// начало транзакции

transaction.Begin();

try

{

// прекратить ожидание сообщений в очереди

queueReceive.EndPeek(asyncResult.AsyncResult);

// получить сообщение из очереди в рамках транзакции

Message message = queueReceive.Receive(transaction);

// в поле CorrelationId должен быть идентификатор сообщения

// с исходным запросом

String messageId = message.CorrelationId;

// есть ли такое сообщение в списке невыполненных запросов?

if (messages.ContainsKey(messageId))

{

if (message.Body is AnswerType)

{

// преобразовать тело сообщения к типу ответа

// и вызвать событие по его обработке

AnswerType answer = (AnswerType) message.Body;

ProcessAnswer(this, messages[messageId], answer);

};

messages.Remove(messageId);

}

// продолжить ожидать сообщения

BeginReceive();

// успешное завершение транзакции

transaction.Commit();

}

catch (Exception e)

{

// отмена транзакции

transaction.Abort();

throw e;

}

}

}

MSMQServer – класс общего вида, принимающий через MSMQ запросы и посылающий

ответы на них.

class MsmqServer<RequestType, AnswerType>:

MsmqUser<RequestType, AnswerType>, IDisposable

{

// очередь приема запросов

private MessageQueue queueReceive;

// событие, вызываемое при приеме запроса

public event ProcessRequestEventHandler<RequestType, AnswerType>

ProcessMessage;

Конструктор класса проверяет наличие очереди.

public MsmqServer(String queueReceiveName, QueueFormatter formatterType):

base(formatterType)

{

// создание очереди приема сообщений, если она не существует

queueReceive = MsmqTools.CreateQueue(queueReceiveName,

QueueType.Transactional);

queueReceive.Formatter = requestFormatter;

}

В методе Dispose происходит закрытие используемых очередей.

{

queueReceive.Close();

queueReceive.Dispose();

}

Функции BeginReceive и EndReceive начинают и прекращают прием ответов сервера,

изменяя обработчик события PeekComplete очереди ответов.

// начать прием запросов от клиента

public void BeginReceive()

{

queueReceive.PeekCompleted += OnPeek;

queueReceive.BeginPeek();

}

// прекратить прием запросов от клиента

public void EndReceive()

{

queueReceive.PeekCompleted -= OnPeek;

}

Метод OnPeek – обработчик события PeekCompleted очереди с запросами. В одну транзакцию входит две операции с очередями – чтения запроса и отправка ответа на него. Для обработки принятого сообщения и создания ответа на него вызывается событие ProcessMessage. В поле ResponseQueue полученного сообщения содержится ссылка на очередь, в которую следует отправить ответ на обработанный запрос.

// обработчки события PeekCompleted очереди с запросами

public void OnPeek(Object source, PeekCompletedEventArgs asyncResult)

{

// создание внутренней транзакции MSMQ

MessageQueueTransaction transaction = new MessageQueueTransaction();

// начало транзакции

transaction.Begin();

try

{

queueReceive.EndPeek(asyncResult.AsyncResult);

// прием cообщения в рамках транзакции

Message message = queueReceive.Receive(transaction);

// в поле ResponseQueue содержится ссылка на очередь,

// куда следует послать ответ на запрос

MessageQueue queueResponse = message.ResponseQueue;

try

{

if (message.Body is RequestType)

{

RequestType request = (RequestType) message.Body;

// вызвать событие обработки запроса

AnswerType answer = ProcessMessage(this, request,

queueResponse);

if ((queueResponse != null) && (answer != null))

{

Message answerMessage = new Message(answer, answerFormatter);

answerMessage.Label = "Answer";

answerMessage.CorrelationId = message.Id;

answerMessage.Recoverable = Recoverable;

// послать собщение в рамках транзакции

queueResponse.Send(answerMessage, transaction);

}

}

}

finally

{

if (queueResponse != null)

{

queueResponse.Close();

queueResponse.Dispose();

}

};

// продолжить прием запросов

BeginReceive();

// завершить транзакцию

transaction.Commit();

}

catch (Exception e)

{

// отменить транзакцию в случае ошибки

Console.WriteLine(e);

transaction.Abort();

throw e;

}

}

}

Класс MsmqTools содержит вспомогательный статический метод для создания очереди сообщений.

static class MsmqTools

{

static public MessageQueue CreateQueue(String queueName)

{

return CreateQueue(queueName, QueueType.Transactional);

}

// функция проверяет наличие очереди и создает ее при необходимости

static public MessageQueue CreateQueue(String queueName,

QueueType type)

{

MessageQueue messageQueue;

// если это частная очередь удаленного компьютера,

// то при попытке проверки ее наличие возникает исключение

try

{

if (!MessageQueue.Exists(queueName))

{

MessageQueue.Create(queueName,

type == QueueType.Transactional);

}

}

catch(Exception)

{

}

MessageQueue messageQueue = new MessageQueue(queueName);

return messageQueue;

}

}

}

Следует отметить, что при работе с общими очередями можно обращаться к очереди по ее пути, например следующим образом.

queueName = @"Server\PublicQueue";

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

queueName = @"Formatname:DIRECT=OS:Computer\Private$\PrivateName";

Имена используемых очередей следует хранить в конфигурационном файле программы.

Выводы по использованию MSMQ

Промежуточная среда Microsoft Message Queuing обеспечивает асинхронный обмен сообщениями и может быть использована программными компонентами распределенной системы в одном из следующих случаях:

– необходимо организовать параллельную обработку заявок несколькими компьютерами;

– одна компонента посылает другой запросы без получения ответов на них;

– взаимодействие компонент не должно быть синхронным;

– требуется интеграция с какими-либо другими независимыми системами, которые могут использовать очереди сообщений (MSMQ или IBM MQ).

Альтернативным способом использования MSMQ являются отложенные компоненты (queued components) среды COM+

Кроме того, существует возможность использовать MSMQ как канал в .NET Remoting, для чего необходимо создать собственный канал.

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


3.4. Технология EJB для построения распределенных систем

Технология EJB (Enterprise JavaBeans) представляет собой один из подходов к построению распределенных систем. С помощью этой технологии разработчику достаточно программировать только бизнес-логику приложения и можно не заниматься стандартными вещами, такими, как обработка транзакций. Данная архитектура предполагает, что подобные стандартные функции - проблема производителя сервера.

К ее конкурентам можно отнести RMI (remote method invocation - вызов удаленных методов), CORBA (common object request broker architecture), DCOM (distributed component object model) и некоторые другие. Надо сказать, что многие принципы CORBA были сознательно положены в основу EJB. Более того, существует стандарт отображения EJB на CORBA, касающийся службы имен и управления транзакциями и безопасностью.

Спецификация EJB определяет следующие цели:

  1.  Облегчить разработчикам создание приложений, избавив их от необходимости реализовывать с нуля такие службы, как транзакции (transactions) и другие. Разработчики могут сконцентрироваться на описании логики своих приложений, оставляя заботы о хранении, передаче и безопасности данных на EJB-систему. При этом все равно имеется возможность самому контролировать и описывать порученные системе процессы.
  2.  Описать основные структуры EJB-системы, описав при этом интерфейсы взаимодействия  между ее компонентами.
  3.  EJB преследует цель стать стандартом для разработки приложений клиент/сервер на Java. Таким же образом, как исходные JavaBeans компоненты от различных производителей можно было составлять вместе с помощью соответствующих RAD-систем, получая в результате работоспособные клиенты, таким же образом серверные компоненты EJB от различных производителей также могут быть использованы вместе. EJB-компоненты, будучи Java-классами, должны работать на любом EJB-совместимом сервере даже без перекомпиляции, что практически нереально для других систем.
  4.  EJB совместима с Java API, может взаимодействовать с другими (не обязательно Java) приложениями, а также совместима с CORBA.

Основная идея, лежавшая в разработке технологии Enterprise JavaBeans - создать такую инфраструктуру для компонент, чтобы они могли бы легко ``вставляться'' (``plug in'') и удаляться из серверов, тем самым увеличивая или снижая функциональность сервера. Каждый компонент в среде EJB должен функционировать внутри контейнера, изолирующего его от ОС сервера.

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

В составе служб серверной среды EJB предусмотрены:

1. Протокол удаленной связи. Java Beans имеет доступ к протоколу удаленного вызова методов (Remote Method Invocation, RMI), входящему в состав Java и работающему непосредственно поверх сетевых протоколов TCP/IP.

2 Служба каталогов. Эта служба обеспечивается через независимый от реализации API-интерфейс Java Naming & Directory Interface (JNDI) компании Sun Microsystems, позволяющий приложениям, написанным на языке Java, пользоваться имеющимися службами каталогов, например, DNS.

3. Служба безопасности. Платформа EJB может использовать все сервисы защиты, предоставляемые стандартным пакетом Java-security от Sun Microsystems. К ним относятся: аутентификация с применением открытого и секретного ключей, шифрование, управление цифровыми ключами и списками контроля доступа.

4. Служба системного администрирования. Эта служба обеспечивается через API-интерфейс Java Management API (JMAPI) компании Sun Microsystems. Он предоставляет набор служб мониторинга, управления и администрирования, а также описание пользовательского интерфейса консоли системного администратора.

5. Служба транзакций. В среде EJB определена модель обработки транзакций, в основу которой положена спецификация Object Transaction Service, разработанная Object Management Group (OMG) (API-интерфейс Java Transaction Service, JTS, в этой среде не используется).

В модели Java Beans предусмотрены средства, позволяющие упаковать компоненты Java Beans для вложения в контейнеры, поддерживающие модель DCOM, в том числе в контейнеры для MS Visual Basic, MS Internet Explorer, MS Office, Lotus Notes. Для этого служит специальный коммуникационный мост, технологической основой которого служит утилита упаковки. Эта утилита для выбранных компонентов Java Beans генерирует библиотеку OLE Type Library и реестровую информацию для интерфейса Win32 ОС Windows. Полученные в результате данные позволяют контейнерам DCOM правильно анализировать, представлять и обрабатывать компоненты Java Beans, например, перехватывать события компонента, инициировать методы его служб, создавать страницы свойств для настройки компонентов.

Базовая модель EJB

Базовая структура EJB состоит из пяти частей:

  •  серверы EJB;
  •  контейнеры EJB, которые работают внутри сервера;
  •  объекты типа home, remote, EJBObjects и EJB, которые работают в контейнерах;
  •  клиенты EJB;
  •  вспомогательные службы, например, JNDI, JTS, службы безопасности и т. д.

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

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

Клиент EJB никогда не имеет прямого доступа к "бину" (bean в аббревиатуре EJB - "боб", или компонент). Любой доступ к bean выполняется посредством методов контейнерно-генерируемых классов, которые в свою очередь вызывают методы этого компонента.

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

Remote-интерфейс перечисляет бизнес-методы, доступные для EJB. EJBObject - это клиентское представление объекта EJB, реализующее remote-интерфейс. В то время как разработчик EJB определяет remote-интерфейс, производитель контейнера предоставляет средства, позволяющие сгенерировать код для соответствующего объекта EJBObject.

Настоящий объект EJB содержится в контейнере EJB и никогда не должен быть напрямую доступен никому, кроме контейнера. Хотя прямой доступ в принципе возможен, применять его не рекомендуется, так как это разрывает связь ("контракт") между bean и контейнером. Контейнер EJB должен служить связующим звеном между всеми обращениями к EJB. По этой причине разработчик EJB не реализует remote-интерфейс в самом EJB.

Клиенты EJB находят определенный контейнер EJB, который содержит объект EJB, через протокол JNDI (Java Naming and Directory Interface, Java-интерфейс именования и каталогов). Затем они используют контейнер EJB для вызовов методов bean-компонента. Клиент EJB получает ссылку только на экземпляр EJBObject - он никогда в действительности не получает ссылку на текущий экземпляр собственно EJB. Когда клиент вызывает метод, экземпляр EJBObject принимает запрос и перенаправляет его соответствующему экземпляру bean, предоставляя всю необходимую дополнительную функциональность. Клиент использует home-объект для нахождения, создания или разрушения экземпляров EJB. Затем он использует экземпляр EJBObject для вызова бизнес-методов экземпляра bean.

Enterprise beans

Понятно, что одно из основных понятий в Enterprise JavaBeans - компонент EJB, который по сути представляет собой отрезок кода, имеющий поля и методы для реализации каждого модуля бизнес-логики. Они могут быть постоянными или непостоянными.

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

Существует два различных типа ``бинов''.

  1.  Session bean представляет собой EJB-компонент, связанный с одним клиентом. ``Бины'' этого типа, как правило, имеют ограниченный срок жизни (хотя это и не обязательно), и редко участвуют в транзакциях. В частности, они обычно не восстанавливаются после сбоя сервера. В качестве примера session bean можно взять ``бин'', который живет в Web-сервере и динамически создает HTML-страницы клиенту, при этом следя за тем, какая именно страница загружена у клиента. Когда же пользователь покидает Web-узел, или по истечении некоторого времени, session bean уничтожается. Несмотря на то, что в процессе своей работы, session bean мог сохранять некоторую информацию в базе данных, его предназначение заключается не в отображении состояния или в работе с ``вечными объектами'', а просто в выполнении некоторых функций на стороне сервера от имени одного клиента.
  2.  Entity bean, наоборот, представляет собой компонент, работающий с постоянной (persistent) информацией, хранящейся, например, в базе данных. Entity beans ассоциируются с элементами баз данных и могут быть доступны одновременно нескольким пользователям. Так как информация в базе данных является постоянной, то и entity beans живут постоянно, ``выживая'', тем самым, после сбоев сервера (когда сервер восстанавливается после сбоя, он может восстановить ``бин'' из базы данных). Например, entity bean может представлять собой строку какой-нибудь таблицы из базы данных, или даже результат операции SELECT. В объектно-ориентированных базах данных, entity bean может представлять собой отдельный объект, со всеми его методами и свойствами.

Средства защиты EJB

Модель Enterprise JavaBeans использует службы защиты на Java, предусмотренные в Java Development Kit. Средства защиты Java-платформы поддерживают сервисы аутентификации и авторизации, ограничивающие доступ к защищенным объектам и методам.

Кроме того, технология EJB автоматизирует процесс использования средств защиты Java-платформы. Правила защиты для каждого bean определены декларативно в пакете объектов AccessControlEntry в объекте deployment descriptor.

Транзакции

Технология EJB требует распределенной системы управления транзакциями, которая поддерживает протоколы двухфазовой фиксации распределенных транзакций. Спецификация Enterprise JavaBeans предусматривает, но не требует осуществления транзакций, основанных на интерфейсе Java Transaction Service (JTS) API.

JTS представляет собой Java-технологию, связанную с механизмом CORBA Object Transaction Service (OTS). Эта технология поддерживает распределенные транзакции, которые могут охватывать множество баз данных на многочисленных системах, координируемых многими менеджерами транзакций. При использовании JTS сервер Enterprise JavaBeans гарантирует, что его транзакции способны охватить многие серверы Enterprise JavaBeans.

Технология Enterprise JavaBeans значительно упрощает процесс разработки приложений, автоматизируя использование распределенных транзакций. Все функции транзакций могут выполняться непосредственно EJB-контейнером и EJB-сервером. Отдельным beans не обязательно создавать операторы разграничения транзакций, включая их в код. И поскольку код транзакций требуется для логики приложений, beans проще писать и переносить посредством различных менеджеров транзакций.

EJB имеет следующие положительные и отрицательные стороны:

Достоинства

  1.  Быстрое и простое создание
  2.  Java-оптимизация
  3.  Кроссплатформенность
  4.  Динамическая загрузка компонент-переходников
  5.  Возможность передачи объектов по значению
  6.  Встроенная безопасность

Недостатки

  1.  Поддержка только одного языка - Java
  2.  Трудность интегрирования с существующими приложениями
  3.  Плохая масштабируемость
  4.  Производительность
  5.  Отсутствие международной стандартизации

Благодаря своей легко используемой Java-модели, EJB является самым простым и самым быстрым способом создания распределенных систем. EJB - хороший выбор для создания RAD-компонент и небольших приложений на языке Java.


Тема 5. Современные технологи разработки распределенных систем

5.1 Технология Web-сервисов

5.1.1 Основы Web-сервисов

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

В основе Web-сервисов лежат следующие универсальные технологии:

TCP/IP – универсальный протокол, понимаемый всеми сетевыми устройствами, от мэйнфреймов до мобильных телефонов и PDA;

HTML – универсальный язык разметки, применяемый для отображения информации устройствами пользователей;

XML (Extensible Markup Language)– универсальный язык для работы с любыми типами данных.

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

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

Веб-сервисы могут использоваться во многих приложениях. Независимо от того, откуда запускаются веб-сервисы, с настольных компьютеров клиентов или с переносных, они могут использоваться для обращения к таким интернет-приложениям, как система предварительных заказов или контроля выполнения заказов. Веб-сервисы пригодны для В2В-интеграции (business-to-business), замыкая приложения, выполняемые различными организациями, в один производственный процесс. Веб-сервисы также могут решать более широкую проблему интеграции приложений предприятия (Enterprise Application Integration, EAI), осуществляя связь нескольких приложений одного предприятия с несколькими другими приложениями. Во всех перечисленных случаях технологии веб-сервисов являются "связующим звеном", объединяющим различные части программного обеспечения.

Как видно из рис. 5.1, веб-сервисы представляют собой оболочку, обеспечивающую стандартный способ взаимодействия с прикладными программными средами, такими как системы управления базами данных (СУБД), .NET, J2EE (Java2 Platform, Enterprise Edition), CORBA (Common Object Request Broker Architecture), посредники пакетов планирования ресурсов предприятия (Enterprise Resource Planning, ERP), брокеров интеграции и пр.

Рис.5.1. Веб-сервисы взаимодействуют с прикладными системами

Интерфейсы веб-сервисов получают из сетевой среды стандартные XML-сообщения, преобразуют XML-данные в формат, "понимаемый" конкретной прикладной программной системой, и отправляют ответное сообщение (последнее - не обязательно). Программная реализация веб-сервисов (базовое программное обеспечение, нижний уровень) может быть создана на любом языке программирования с использованием любой операционной системы и любого связующего программного обеспечения (middleware).

Простой пример: поиск информации 

В настоящее время большинство сервисов вызываются по Сети посредством ввода данных в HTML-формы и отправки этих данных сервису путем добавления их в строку унифицированного указателя информационного ресурса (Uniform Resource Locator, URL):

http://www.google.com/search?q=Skate+boots&btnG=Google+Search

Этот пример иллюстрирует простоту веб-взаимодействия (например, поиска, покупки акций или запроса маршрута движения), где параметры и ключевые слова внедряются непосредственно в URL. В данном случае представлен простой запрос поиска skate boots (ботинки с коньками) в строке обращения к поисковой машине Google. Ключевое слово search (искать) представляет сервис, к которому будет осуществлено обращение, а параметр Skate+boots является строкой поиска, которая была введена в HTML-форме на странице веб-сайта Google. Сервис поиска Google передаст этот запрос к различным поисковым машинам, которые вернут список URL для страниц, на которых имеется соответствие параметру поиска Skate+boots. Данный малоэффективный способ поиска в Сети полностью основан на установлении соответствия указанной текстовой строки и индексированных HTML-страниц.

XML - лучший способ отправки данных. XML предоставляет значительные преимущества при передаче данных через Интернет. Теперь предыдущий запрос можно представить в виде XML-документа:

<SOAP-ENV:Body>

<s:SearchRequest

xmlns:s="www.xmlbus.com/SearchService">

 <pl>Skate</pl>

<p2>boots</p2>

<p3>size 7.5</p3>

</s:SearchRequest>

</SOAP-ENV:Body>

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

Данный пример представлен в форме SOAP-сообщения (Simple Object Access Protocol) - стандартной формы обмена XML-сообщениями - одной из технологий, лежащих в основе веб-сервисов. В SOAP-сообщении имя запрашиваемого сервиса и входные параметры представлены в виде отдельных XML-элементов. Рассматриваемый пример также иллюстрирует использование пространства имен XML (xmlns:), еще одного важного элемента веб-сервисов. Благодаря тому, что XML-документы поддерживают разные типы данных, сложные структуры и объединение схем, современные технологии веб-сервисов обеспечивают значительное преимущество над существующими возможностями обращения к программным приложениям посредством HTML и URL.

Следующее поколение Сети

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

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

ОБЩЕЕ ВЗАИМОПОНИМАНИЕ

Технология веб-сервисов существует на очень высоком уровне абстракции, позволяя поддерживать множество одновременных определений, которые иногда бывают противоречивы. На простейшем уровне веб-сервисы могут восприниматься как интернет-ориентированные текстовые брокеры интеграции. Любые данные могут преобразовываться в ASCII-текст и обратно, и этот подход в течение долгого времени был общим знаменателем для систем графического вывода и систем управления базами данных. Ориентированные на использование текста системы также лежат в основе успешного развития Интернета, на котором базируется дополнительная абстракция веб-сервисов. Любой компьютер или операционная система может поддерживать HTML, браузеры и веб-сервисы; и при получении по сети файлов им совершенно безразлично и даже неизвестно, с каким типом прикладной системы они взаимодействуют.

Преимущества и недостатки веб-сервисов.

К преимуществам веб-сервисов можно отнести следующее:

  •  Веб-сервисы позволяют компании интегрировать свои бизнес-процессы с бизнес-процессами бизнес-партнеров и клиентов при меньшей стоимости, чем с использованием других интеграционных технологий. Стоимость подобных решений на основе веб-сервисов доступна даже для SMB (Small and Medium Business), что откроет для таких компаний новые перспективы развития;
  •  Поскольку веб-сервисы организуются в публичные реестры (UDDI-реестры, ebXML-реестры или иные), доступные заинтересованным лицам по всему миру, порог выхода компаний на новые рынки снижается, возможности же для наращивания клиентской базы напротив возрастают;
  •  Веб-сервисы обеспечивают преемственность в отношении уже имеющихся в компании ИС, т. е. можно сказать, что веб-сервисы надстраиваются над существующими ИС, но не вместо них. Таким образом, обеспечивается сохранность уже сделанных инвестиций в IT-инфраструктуру и не идет увеличения требуемых, поскольку нет необходимости в радикальных изменениях;
  •  Построение новых корпоративных решений с применением веб-сервисов реализуется быстрее и совокупно дешевле, поскольку основное внимание сосредотачивается на создании бизнес-логики решения, программирование самих веб-сервисов лишь по необходимости “обрамляет” этот процесс, не требуя больших трудозатрат за счет эффективного применения повторно используемого кода и адаптированных средств разработки (IDE и SDK).

К недостаткам (минусам) веб-сервисов можно отнести:

  •  Стандарты интеграции бизнес-процессов, вопросы управления транзакциями и выработка единых бизнес- и IT-политик взаимодействующих посредством веб-сервисов компаний находятся пока на стадии разработки (мы отметим следующие начинания: Web Services Flow Language (WSFL), Business Process Execution Language 4 Web Services (BPEL4WS (аббревиатура “BPEL” произносится кратко как “бипль”)) корпорации IBM, XLANG корпорации Microsoft и спецификации WS-Coordination и WS-Transaction – результат сотрудничества IBM, Microsoft и BEA). Очевидно, без их четкой формализации и опубликования построение ИС на основе веб-сервисов может идти лишь с переменным успехом;
  •  Динамическое использование информации бизнес-реестров веб-сервисов, вызов веб-сервисов, требует решения вопросов доверительности отношений между различными бизнес-реестрами. Кроме того, есть трудности в совместном использовании бизнес-реестров различных форматов (например, задача поиска определенного веб-сервиса в UDDI-реестре и ebXML-реестре требует различных подходов в силу различия XML-документов, описывающих один и тот же веб-сервис в каждом из этих реестров. Хотя, надо отметить, что есть попытки решить эту проблему созданием единого браузера реестров. В качестве примера - графическая утилита Registry Browser корпорации Sun Microsystems, реализующая набор интерфейсов JAXR (Java API for XML Registries);
  •  Добавление к функциям сервера приложений функциональности провайдера веб-сервисов в силу новизны технологий может представлять определенную трудность;
  •  Вопросы безопасности функционирования ИС на основе веб-сервисов пока не урегулированы до конца. Спецификация WS-Security – продукт деятельности корпораций IBM и Microsoft – в настоящее время достаточно молода, не “устоялась” и частично все еще дорабатывается. Однако, в силу общности положений спецификации WS-Security, уже готовится к выпуску следующий слой спецификаций, посвященных вопросам безопасности: Web Services Policy Assertions, Web Services Policy Attachments, Web Services Policy Framework, Web Services Trust, Web Services Secure Conversation, Web Services Federation.

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

Определение веб-сервиса

Назовем сервисом (service) ресурс, реализующий бизнес-функцию, обладающий следующими свойствами:

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

Веб-сервисом (см. документ W3C “Web-services architecture requirements”) называется программная система, идентифицируемая строкой URI, чьи интерфейсы и привязки определены и описаны посредством XML. Описание этой программной системы может быть найдено другими программными системами, которые могут взаимодействовать с ней согласно этому описанию посредством сообщений, основанных на XML, и передаваемых с помощью Интернет-протоколов.

5.1.2 Взаимодействие с веб-сервисами

Веб-сервисы поддерживают несколько способов обмена сообщениями. Уровень абстракции, на котором оперируют веб-сервисы, подразумевает такие стили взаимодействия, как эмуляцию удаленного вызова процедуры (Remote Procedure Call, RPC), асинхронный обмен сообщениями, однонаправленную передачу сообщений, широковещание и публикацию/подписку. Основные СУБД, такие как Oracle, SQL Server и DB2, поддерживают анализ XML и службы преобразования, обеспечивая непосредственное взаимодействие между веб-сервисами и СУБД. Производители связующего программного обеспечения обычно также предоставляют возможность привязки веб-сервисов к своим программным системам (серверам приложений и брокерам интеграции). Следовательно, для пользователя взаимодействие с веб-сервисами может проявляться в интерактивной или пакетной форме, поддерживающей синхронную и асинхронную модели связи; а также как пользовательский интерфейс, написанный с использованием Java, VB (Visual Basic), офисных приложений, браузеров или "толстых" клиентов СУБД. Такое взаимодействие может привязываться к любому типу базовой (более низкого уровня) программной системы.

Веб-сервисы выполняют RPC- и документно-ориентированное взаимодействия. Стандарты и технологии веб-сервисов обычно подразумевают два основных типа моделей взаимодействия приложений:

-  удаленный вызов процедуры (онлайновая);

-  документно-ориентированный (пакетная).

Эти два типа взаимодействия мы и рассмотрим в последующих разделах.

RPC-ориентированные взаимодействия

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

Рис. 5.2. Веб-сервисы поддерживают интерактивный заказ в форме запроса/ответа

Документно-ориентированные взаимодействия

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

Документно-ориентированные взаимодействия зачастую предполагают, что использующие веб-сервисы стороны заранее согласовали порядок оформления общих документов, таких как заказ на приобретение, счет за доставку или общий счет. Эти стороны обычно идентифицируются как "торговые партнеры" или "сотрудничающие партнеры". Торговые партнеры также согласовывают общий поток выполнения процесса или модель взаимодействия при обмене документами, например, оговаривают необходимость подтверждения квитанции заказа на приобретение, передачу специальной информации о состоянии в ответ на запрос заказа или отправку сигнала оповещения по электронной почте после отгрузки заказа. В ходе реализации бизнес-процесса необходим обмен полными документами. Если до этого документ содержал общую, фрагментированную информацию, то теперь требуется согласованное заполнение специальных разделов, таких как цена покупки или обязательная дата доставки.

Рис. 5.3.  Веб-сервис обрабатывает полный заказ на поставку

5.1.3. Технология веб-сервисов

Порядок описания, поиска и взаимодействия веб-сервисов друг с другом определяют стандарты. Взаимодействующие через Интернет программы должны уметь обнаруживать друг друга, находить информацию, позволяющую им осуществить связь, понимать, какая модель должна быть применена (простая, типа "запрос/ответ", или более сложная последовательность), и договариваться об использовании таких услуг, как защита информации, подтверждение передачи сообщений и составление сделок. Некоторые из этих сервисов реализуются существующими технологиями и предлагаемыми стандартами, а другие - нет. Использующее веб-сервисы сообщество стремится удовлетворить все эти требования, но это - эволюционный процесс, как и сам Интернет. С самого начала инфраструктура и стандарты веб-сервисов подразумевали возможность расширения (так же как до них XML и HTML), что позволяет использовать их сразу же после появления новых стандартов и технологий.

Веб-сервисы требуют использования нескольких смежных XML-технологий.

  1.  Язык XML - фундамент, на котором строятся веб-сервисы. Он предоставляет язык определения данных и порядок их обработки. XML представляет семейство связанных спецификаций, публикуемых и поддерживаемых интернет-консорциумом (World Wide Web Consortium, W3C) и другими организациями.
  2.  SOAP (Simple Object Access Protocol), разработанный консорциумом W3C, определяет формат запросов к Web-сервисам. Сообщения между Web-сервисом и его пользователем пакуются в так называемые SOAP-конверты (SOAP envelopes, иногда их ещё называют XML-конвертами). Само сообщение может содержать либо запрос на осуществление какого-либо действия, либо ответ - результат выполнения этого действия.
  3.  WSDL (Web Services Description Language) - технология, основанная на XML, определяющая интерфейсы веб-сервисов, типы данных и сообщений, а также модели взаимодействия и протоколы связывания. Перед развертыванием сервиса разработчик составляет его описание на языке WSDL, указывает адрес Web-сервиса, поддерживаемые протоколы, перечень допустимых операций, форматы запросов и ответов.
  4.  Технология UDDI (Universal Description, Discovery and Integration) - реестр веб-сервисов и механизм поиска. Он используется для хранения и упорядочения деловой информации, а также для нахождения указателей на интерфейсы веб-сервисов.

5.1.4. Пример использования

Стандарты веб-сервисов обычно используются совместно и согласованно. После обнаружения WSDL в UDDI или другом месте генерируется SOAP-сообщение для отправки на удаленный сайт.

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

SOAP-процессор отправляющего компьютера преобразует данные из собственного ("родного") формата в тип данных, предопределенный в соответствии с содержащейся в WSDL-файле XML-схемой на основе таблиц преобразования для текстов, значений с плавающей точкой и других данных. Таблицы преобразования "связывают" собственные типы данных с соответствующими конкретной XML-схеме. (Стандартное преобразование типов широко используется в Java, Visual Basic, CORBA и других известных системах. Многие средства XML позволяют настраивать специальные преобразования типов.) SOAP-процессор получающего компьютера выполняет обратное преобразование данных из типов XML-схемы в собственные типы данных.

Файлы описаний веб-сервисов обычно регистрируются с помощью URL. URL, повсеместно используемый в Сети, указывает на IP-адрес, соответствующий веб-ресурсу. Схемы веб-сервисов являются одной из форм веб-ресурса, они содержатся в доступных через Интернет файлах и к ним применим тот же механизм, что используется при загрузке HTML-файлов. Главное отличие между загрузкой HTML-файла и обращением к ресурсу веб-сервиса заключается в том, что веб-сервис оперирует XML-документами, а не HTML-документами и опирается на соответствующие технологии, такие как использование схем, преобразование, проверка подлинности, что и обеспечивает поддержку удаленного соединения приложений. Но способ, согласно которому схемы веб- сервисов публикуются и загружаются, одинаков: HTTP-операция по указанному URL.

Рис. 5.4. Веб-сервисы используют XML-документы и осуществляют преобразование данных

Для проверки достоверности сообщений веб-сервисы используют XML-схемы. После получения документа реализация веб-сервиса сначала должна проанализировать XML-сообщение и удостовериться в корректности данных, выполнить проверку качества услуг (Quality-of-Service), такую как проверку политики безопасности или соглашений торговых партнеров, а затем произвести последовательность связанных с данным документом коммерческих операций. Веб-сервис на вымышленном нами сайте skateboots.com размещен в папке skateboots.com/ order, на которую и указывает URL.

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

Размещенные по адресу skateboots.com программы представляют собой прослушивающий HTTP-процесс, связанный с соответствующими веб-сервисами для распознавания XML-сообщений, определенных в данном формате. Эти программы включают в себя XML-анализаторы и преобразователи. Кроме того, они осуществляют конвертацию данных SOAP-сообщения в форматы, необходимые для системы ввода заказов компании Skateboots Company.

Технологии веб-сервисов сформировались из основных структур. Этих технологий достаточно для построения, развертывания и публикации базовых веб-сервисов. На самом деле, необходим лишь базовый протокол SOAP. С момента появления веб-сервисов к ним все время добавляются другие технологии. Хотя для деловой связи, а также для создания "моста" с несовместимыми технологиями вполне достаточно базовых принципов, данная форма веб-взаимодействия тем не менее была одобрена очень быстро.

5.2. Определение сервисно-ориентированной архитектуры

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

Компонентная модель, состоящая из отдельных функциональных модулей приложений, называемых сервисами, имеющих определенные согласно некоторым общим правилам интерфейсы и механизм взаимодействия между собой, называется сервисно-ориентированной архитектурой (Service-Oriented Architecture, SOA).

Переходя в мир абстракций, можно дать следующее, более сильное, определение сервисно-ориентированной архитектуры:

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

На сегодняшний день устоявшегося, принятого IT-сообществом, определения SOA нет. Здесь мы приводим определение, которое, на наш взгляд, наиболее полно и точно отражает современное состояние этой концепции).

Поясним второе определение:

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

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

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

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

Требования к SOA

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

обеспечивать преемственность инвестиций в IT, сохранение существующих информационных систем и их совместное эффективное использование для повышения ROI от IT-вложений;

обеспечивать реализацию различных типов интеграции:

- пользовательская интеграция (user integration) - обеспечение взаимодействия информационной системы с конкретным пользователем;

- интеграция приложений (application connectivity) - обеспечение взаимодействия приложений;

- интеграция процессов (process integration) - интеграция бизнес-процессов;

- информационная интеграция (information integration) - интеграция с целью обеспечения доступности информации и данных;
-
интеграция новых приложений (build to integrate) - интеграция новых приложений и сервисов в существующие информационные системы.

обеспечивать поэтапность внедрения вновь созданных и миграции существующих информационных систем;

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

позволять реализацию различных моделей построения информационных систем, в особенности таких как портальные решения, grid-системы.

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

SOA и веб-сервисы - в чем разница?

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

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

5.3. Преимущества SOA

Концепции SOA и веб-сервисов не новы; на протяжении последних десяти лет были и другие технологии построения распределенных информационных систем, например, CORBA и DCOM. Однако, со временем решения, построенные на их основе перестали удовлетворять основным требованиям, предъявляемым к бизнес-решениям: максимально низкая TCO, максимально высокий ROI, короткий цикл разработки и внедрения информационной системы, широкие возможности интеграции разнородных систем.

В отличие от известных моделей технологии веб-сервисов и SOA:

являются open-source;

основаны на общепринятых и общеупотребимых технологиях и стандартах: XML, HTTP, TCP/IP;

позволяют достичь наилучших показателей TCO и ROI, нежели какие-либо иные существующие на сегодняшний день интеграционные технологии;

находятся на уровне зрелости, необходимом и достаточном для успешного применения большим количеством ISV (англ. Independent Software Provider) по всему миру.

5.4 Стек технологий веб-сервисов

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

Рис. 1: Стек технологий веб-сервисов

Стек технологий веб-сервисов принципиально разбивается на следующие две составляющие:

  •  технологии, обеспечивающие функциональность веб-сервисов (Functions);
  •  технологии, обеспечивающие качество сервиса веб-сервисов (Quality of service).

Эти составляющие в свою очередь образуются несколькими слоями (layers):

  •  технологии, обеспечивающие функциональность веб-сервисов:
  •  транспортный слой (transport layer);
  •  коммуникационный слой (service communication layer);
  •  слой описаний сервисов (service description layer);
  •  сервисный слой (service layer);
  •  слой бизнес-процессов (business process layer);
  •  слой реестров сервисов (service registry layer).
  •  технологии, обеспечивающие качество сервиса веб-сервисов:
  •  слой политик (policy layer);
  •  слой безопасности (security layer);
  •  слой транзакций (transaction layer);
  •  слой управления (management layer).

В целях понимания назначения слоев, дадим краткое описание каждого из них.

№ п/п

Наименование слоя

Назначение слоя

Технологии, реализующие слой 

Функциональность (Functions)

1

Транспортный слой (Transport layer)

Описывает средства обмена данными между веб-сервисами

Стандартные: HTTP, JMS (для Java-приложений), SMTP

Нарождающиеся: WS-ReliableMessaging, BEEP

2

Коммуникационный слой (Service communication layer)

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

Стандартные: SOAP

Нарождающиеся:REST

3

Слой описаний сервисов (Service description layer)

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

- операционное (operational);

- полное (complete)

Стандартные: XML, WSDL

Нарождающиеся: ebXML

4

Сервисный слой (Service layer)

Описывает программное обеспечение, вызываемое с помощью WSDL-описаний интерфейсов веб-сервисов. В частности, это сами веб-сервисы

5

Слой бизнес-процессов (Business process layer)

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

Стандартные: в настоящее время нет

Нарождающиеся: BPEL4WS

6

Слой реестров сервисов (Service registry layer)

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

Стандартные: UDDI

Нарождающиеся: WS-Inspection

Качество сервиса (Quality of service)

7

Слой политик (Policy layer)

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

Стандартные: в настоящее время нет

Нарождающиеся: WS-Policy, WS-PolicyAssertions и WS-PolicyAttachment

8

Слой безопасности (Security layer)

Описывает возможности обеспечения безопасности веб-сервисов и безопасности их функционирования (авторизация, аутентификация и разделение доступа)

Стандартные: WS-Security

Нарождающиеся: WS-SecureConversation, WS-Federation, WS-Authorization, WS-Trust и WS-Privacy

9

Слой транзакций (Transaction layer)

Описывает свойство транзакционности распределенных систем на основе веб-сервисов для обеспечения надежности их функционирования

Стандартные: в настоящее время нет

Нарождающиеся: WS-Transaction и WS-Coordination

10

Слой управления (Management layer)

Описывает возможности управления веб-сервисами и характеристиками их функционирования

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

5.5. Принципы взаимодействия веб-сервисов в рамках сервисно-ориентированной архитектуры

Итак, технологический фундамент веб-сервисов образуется следующими технологиями:

  •  eXtensible Markup Language (XML);
  •  Simple Object Access Protocol (SOAP);
  •  Universal Description, Discovery and Integration (UDDI);
  •  Web Services Description Language (WSDL).

Данные технологии обеспечивают реализацию базовых свойств веб-сервиса, описанных в его определении. Они же лежат в основе взаимодействия веб-сервисов в рамках сервисно-ориентированной архитектуры (см. Рис.2).

Рис. 2: Взаимодействие между компонентами сервисно-ориентированной архитектуры

Различают следующие три основных архитектурных компонента сервисно-ориентированной архитектуры:

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

Каждый компонент может играть либо лишь одну роль (быть, например, только пользователем сервиса) либо одновременно сразу несколько ролей (например, быть провайдером одних сервисов и пользователем других).

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

В ходе взаимодействия друг с другом компоненты сервисно-ориентированной архитектуры выполняют следующие основные операции:

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

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

связывание и вызов: после получения описания сервиса, пользователь сервиса должен иметь возможность вызвать и использовать сервис в соответствии с описанием сервиса.

Рассматривая взаимодействие компонентов сервисно-ориентированной архитектуры необходимо отметить наличие (и различие) следующих двух артефактов:

описание сервиса: определяет формат запроса и отклика при взаимодействии пользователя сервиса и провайдера сервиса, а также требуемое качество сервиса;

сервис: собственно сервис, который может быть вызван и использован пользователем сервиса в соответствии с опубликованным интерфейсом сервиса.

С целью выработки и популяризации стандартов, описывающих взаимодействие веб-сервисов в рамках СОА, создано международное объединение около 150 ведущих компаний, называющееся WS-I (Web Services Interoperability Organization). Важным результатом работы данного объединения стало создание и утверждение в 2003 году так называемого WS-I Basic Profile 1.0 - пакета базовых спецификаций веб-сервисов, взаимоувязанных с целью обеспечения широких возможностей взаимодействия веб-сервисов. В настоящее время в данный профиль входят следующие спецификации технологий:

SOAP 1.1;

WSDL 1.1;

UDDI 2.0;

XML 1.0;

XML Schema Part 1: Structures;

XML Schema Part 2: Datatypes;

RFC2246: The Transport Layer Security Protocol 1.0;

RFC2459: Internet X.509 Public Key Infrastructure Certificate and CRL Profile;

RFC2616: HyperText Transfer Protocol 1.1;

RFC2818: HTTP over TLS;

RFC2965: HTTP State Management Mechanism;

Secure Sockets Layer Protocol 3.0.

Кроме того, в профиле описаны сценарии, демонстрирующие основные методы организации взаимодействия между веб-сервисами.

Для создания Web-сервисов могут использоваться такие инструменты, как Open Net (компании Sun), .NET (Microsoft) и Web Services (IBM). Существуют также инструменты с открытыми кодами (open source frameworks), например, проект Mono Project

(www.go-mono.com), который предоставляет систему компиляции, выполнения кода и библиотек для работы одних и тех же Web-сервисов на всех платформах, включая Unix.


Тема 7. Распределенные БД

7.1. Свойства РБД

Распределенные базы данных невозможно рассматривать вне контекста более общей и более значимой темы распределенных информационных систем.

Под распределенной (distributed database - ddb) обычно подразумевают базу данных, включающую фрагменты из нескольких баз данных, которые располагаются на различных узлах сети компьютеров, и, возможно управляются различными СУБД. Распределенная база данных выглядит с точки зрения пользователей и прикладных программ как обычная локальная база данных. В этом смысле слово "распределенная" отражает способ организации базы данных, но не внешнюю ее характеристику. ("распределенность" базы данных невидима извне).

Определение Дэйта

Возможно лучшее определение распределенных баз данных (ddb) предложил Дэйт. Он установил 12 свойств или качеств идеальной ddb:

  •  Локальная автономия (local autonomy)
  •  Независимость узлов (no reliance on central site)
  •  Непрерывное функционирование (continuous operation)
  •  Прозрачность расположения (location independence)
  •  Прозрачная фрагментация (fragmentation independence)
  •  Прозрачное тиражирование (replication independence)
  •  Обработка распределенных запросов (distributed query processing)
  •  Обработка распределенных транзакций (distributed transaction processing)
  •  Независимость от оборудования (hardware independence)
  •  Независимость от операционных систем (operationg system independence)
  •  Прозрачность сети (network independence)
  •  Независимость от баз данных (database independence)

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

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

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

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

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

Рассмотрим пример, иллюстрирующий оба типа фрагментации. Имеется таблица employee (emp_id, emp_name, phone), определенная в базе данных на узле в Фениксе. Имеется точно такая же таблица, определенная в базе данных на узле в Денвере. Обе таблицы хранят информацию о сотрудниках компании. Кроме того, в базе данных на узле в Далласе определена таблица emp_salary (emp_id, salary). Тогда запрос "получить информацию о сотрудниках компании" может быть сформулирован так:

select * from employee@phoenix, employee@denver order by emp_id

В то же время запрос "получить информацию о заработной плате сотрудников компании" будет выглядеть следующим образом:

select employee.emp_id, emp_name, salary from employee@denver, employee@phoenix, emp_salary@dallas order by emp_id

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

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

select customer.name, customer.address, order.number, order.date from customer@london, order@paris where customer.cust_number = order.cust_number

Обработка распределенных транзакций. Это качество ddb можно трактовать как возможность выполнения операций обновления распределенной базы данных (insert, update, delete), не разрушающее целостность и согласованность данных. Эта цель достигается применением двухфазного протокола фиксации транзакций (two-phase commit protocol), ставшего фактическим стандартом обработки распределенных транзакций. Его применение гарантирует согласованное изменение данных на нескольких узлах в рамках распределенной (или, как ее еще называют, глобальной) транзакции.

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

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

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

Независимость от баз данных. Это качество означает, что в распределенной системе могут использоваться СУБД различных производителей, и возможны операции поиска и обновления в базах данных различных моделей и форматов.

Исходя из определения Дэйта, можно рассматривать ddb как слабосвязанную сетевую структуру, узлы которой представляют собой локальные базы данных. Локальные базы данных автономны, независимы и самоопределены; доступ к ним обеспечиваются СУБД, в общем случае от различных поставщиков. Связи между узлами - это потоки тиражируемых данных. Топология ddb варьируется в широком диапазоне - возможны варианты иерархии, структур типа "звезда" и т.д. В целом топология ddb определяется географией информационной системы и направленностью потоков тиражирования данных.

7.2. Механизм распределенных транзакций

Ввиду важности механизма транзакций и свойств транзакционности, остановимся на них подробнее.

Определение. Транзакция -

Свойства транзакций

Виды транзакций

Распределенные транзакции

7.3. Целостность данных

В ddb поддержка целостности и согласованности данных, ввиду свойств 1-2, представляет собой сложную проблему. Ее решение - синхронное и согласованное изменение данных в нескольких локальных базах данных, составляющих ddb - достигается применением протокола двухфазной фиксации транзакций. Если ddb однородна - то есть на всех узлах данные хранятся в формате одной базы и на всех узлах функционирует одна и та же СУБД, то используется механизм двухфазной фиксации транзакций данной СУБД. В случае же неоднородности ddb для обеспечения согласованных изменений в нескольких базах данных используют менеджеры распределенных транзакций. Это, однако, возможно, если участники обработки распределенной транзакции - СУБД, функционирующие на узлах системы, поддерживают xa-интерфейс, определенный в спецификации dtp консорциума x/open. В настоящее время xa-интерфейс имеют ca-openingres, informix, microsoft sql server, oracle, sybase. Если в ddb предусмотрено тиражирование данных, то это сразу предъявляет дополнительные жесткие требования к дисциплине поддержки целостности данных на узлах, куда направлены потоки тиражируемых данных. Проблема в том, что изменения в данных инициируются как локально - на данном узле - так и извне, посредством тиражирования. Неизбежно возникают конфликты по изменениям, которые необходимо отслеживать и разрешать.

7.4 Прозрачность расположения

Это качество ddb в реальных продуктах должно поддерживаться соответствующими механизмами. Разработчики СУБД придерживаются различных подходов. Рассмотрим пример из oracle. Допустим, что ddb включает локальную базу данных, которая размещена на узле в Лондоне. Создадим вначале ссылку (database link), связав ее с символическим именем (london_unix), транслируемым в ip-адрес узла в Лондоне.

create public database link london.com connect to london_unix using oracle_user_id;

Теперь мы можем явно обращаться к базе данных на этом узле, запрашивая, например, в операторе select таблицу, хранящуюся в этой базе:

select customer.cust_name, order.order_date from customer@london.com, order where customer.cust_number = order.cust_number;

Очевидно, однако, что мы написали запрос, зависящий от расположения базы данных, поскольку явно использовали в нем ссылку. Определим customer и customer@london.com как синонимы:

create synonym customer for customer@london.com;

и в результате можем написать полностью независимый от расположения базы данных запрос:

select customer.cust_name, order.order_date from customer, order where customer.cust_number = order.cust_number

Задача решается с помощью оператора sql create synonym, который позволяет создавать новые имена для существующих таблиц. При этом оказывается возможным обращаться к другим базам данных и к другим компьютерам. Так, запись в СУБД informix

create synonym customer for client@central:smith.customer

означает, что любое обращение к таблице customer в открытой базе данных будет автоматически переадресовано на компьютер central в базу данных client к таблице customer. Оказывается возможным переместить таблицу из одной базы данных в другую, оставив в первой базе ссылку на ее новое местонахождение, при этом все необходимые действия для доступа к содержимому таблицы будут сделаны автоматически. Мы уже говорили выше о горизонтальной фрагментации. Рассмотрим пример иерархически организованной ddb, на каждом из узлов которой содержится некоторое подмножество записей таблицы customer:

С помощью create synonym можно определить, например, таблицу структуры customer, в которой хранятся строки с записями о клиентах компании, находящихся в Японии:

create synonym japan_customer for customer@hq.sales.asia.japan

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

7.5. Обработка распределенных запросов

Выше уже упоминалось это качество ddb. Обработка распределенных запросов (distributed query -dq) - задача, более сложная, нежели обработка локальных и она требует интеллектуального решения с помощью особого компонента - оптимизатора dq. Обратимся к базе данных, распределенной по двум узлам сети. Таблица detail хранится на одном узле, таблица supplier - на другом. Размер первой таблицы - 10000 строк, размер второй - 100 строк (множество деталей поставляется небольшим числом поставщиков). Допустим, что выполняется запрос:

select detail_name, supplier_name, supplier_address from detail, supplier where detail.supplier_number = supplier.supplier_number;

Результирующая таблица представляет собой объединение таблиц detail и supplier, выполненное по столбцу detail.supplier_number (внешний ключ) и supplier.supplier_number (первичный ключ). Данный запрос - распределенный, так как затрагивает таблицы, принадлежащие различным локальным базам данных. Для его нормального выполнения необходимо иметь обе исходные таблицы на одном узле. Следовательно, одна из таблиц должна быть передана по сети. Очевидно, что это должна быть таблица меньшего размера, то есть таблица supplier. Следовательно, оптимизатор dq запросов должен учитывать такие параметры, как, в первую очередь, размер таблиц, статистику распределения данных по узлам, объем данных, передаваемых между узлами, скорость коммуникационных линий, структуры хранения данных, соотношение производительности процессоров на разных узлах и т.д. От интеллекта оптимизатора dq впрямую зависит скорость выполнения распределенных запросов.

7.7. Межоперабельность

В контексте ddb межоперабельность означает две вещи. Во-первых, - это качество, позволяющее обмениваться данными между базами данных различных поставщиков. Как, например, тиражировать данные из базы данных informix в oracle и наоборот? Известно, что штатные средства тиражирования в составе данной конкретной СУБД позволяют переносить данные в однородную базу. Так, средствами ca-ingres/replicator можно тиражировать данные только из ingres в ingres. Как быть в неоднородной ddb? Ответом стало появление продуктов, выполняющих тиражирование между разнородными базами данных.

Во-вторых, это возможность некоторого унифицированного доступа к данным в ddb из приложения. Возможны как универсальные решения (стандарт odbc), так и специализированные подходы. Очевидный недостаток odbc - недоступность для приложения многих полезных механизмов каждой конкретной СУБД, поскольку они могут быть использованы в большинстве случаев только через расширения sql в диалекте языка данной СУБД, но в стандарте odbc эти расширения не поддерживаются.

Специальные подходы - это, например, использование шлюзов, позволяющее приложениям оперировать над базами данных в "чужом" формате так, как будто это собственные базы данных. Вообще, цель шлюза - организация доступа к унаследованным (legacy) базам данных и служит для решения задач согласования форматов баз данных при переходе к какой-либо одной СУБД. Так, если компания долгое время работала на СУБД ims и затем решила перейти на oracle, то ей очевидно потребуется шлюз в ims. Следовательно, шлюзы можно рассматривать как средство, облегчающее миграцию, но не как универсальное средство межоперабельности в распределенной системе. Вообще, универсального рецепта решения задачи межоперабельности в этом контексте не существует - все определяется конкретной ситуацией, историей информационной системы и массой других факторов. ddb конструирует архитектор, имеющий в своем арсенале отработанные интеграционные средства, которых на рынке сейчас очень много.

7.7. Технология тиражирования данных

Принципиальная характеристика тиражирования данных (data replication - dr) заключается в отказе от физического распределения данных. Суть dr состоит в том, что любая база данных (как для СУБД, так и для работающих с ней пользователей) всегда является локальной; данные размещаются локально на том узле сети, где они обрабатываются; все транзакции в системе завершаются локально.
Тиражирование данных - это асинхронный перенос изменений объектов исходной базы данных в базы, принадлежащим различным узлам распределенной системы. Функции dr выполняет, как правило, специальный модуль СУБД - сервер тиражирования данных, называемый репликатором (так устроены СУБД ca-openingres и sybase). В informix-online dynamic server репликатор встроен в сервер, в oracle 7 для использования dr необходимо приобрести дополнительно к oracle7 dbms опцию replication option.
Специфика механизмов dr зависит от используемой СУБД. Простейший вариант dr - использование "моментальных снимков" (snapshot). Рассмотрим
 пример из oracle:

create snapshot unfilled_orders refrash complete start with to_date ('dd-mon-yy hh23:mi:55') next sysdate + 7 as select customer_name, customer_address, order_date from customer@paris, order@london where customer.cust_name = order.customer_number and order_complete_flag = "n";

"Моментальный снимок" в виде горизонтальной проекции объединения таблиц customer и order будет выполнен в 23:55 и будет повторятся каждые 7 дней. Каждый раз будут выбираться только завершенные заказы.

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

Детали тиражирования данных полностью скрыты от прикладной программы; ее функционирование никак не зависят от работы репликатора, который целиком находится в ведении администратора базы данных. Следовательно, для переноса программы в распределенную среду с тиражируемыми данными не требуется ее модификации. В этом, собственно, состоит качество 6 в определении Дэйта.
Синхронное обновление ddb и dr-технология - в определенном смысле антиподы. Краеугольный камень первой - синхронное завершение транзакций одновременно на нескольких узлах распределенной системы, то есть синхронная фиксация изменений в ddb. ee "Ахиллесова пята" - жесткие требования к производительности и надежности каналов связи. Если база данных распределена по нескольким территориально удаленным узлам, объединенным медленными и ненадежными каналами связи, а число одновременно работающих пользователей составляет сотни и выше, то вероятность того, что распределенная транзакция будет зафиксирована в обозримом временном интервале, становится чрезвычайно малой. В таких условиях (характерных, кстати, для большинства отечественных организаций) обработка распределенных данных практически невозможна.
dr-технология не требует синхронной фиксации изменений, и в этом ее сильная сторона. В действительности далеко не во всех задачах требуется обеспечение идентичности БД на различных узлах в любое время. Достаточно поддерживать тождественность данных лишь в определенные критичные моменты времени. Можно накапливать изменения в данных в виде транзакций в одном узле и периодически копировать эти изменения на другие узлы.
Налицо преимущества dr-технологии. Во-первых, данные всегда расположены там, где они обрабатываются - следовательно, скорость доступа к ним существенно увеличивается. Во-вторых, передача только операций, изменяющих данные (а не всех операций доступа к удаленным данным), и к тому же в асинхронном режиме позволяет значительно уменьшить трафик. В-третьих, со стороны исходной базы для принимающих баз репликатор выступает как процесс, инициированный одним пользователем, в то время как в физически распределенной среде с каждым локальным сервером работают все пользователи распределенной системы, конкурирующие за ресурсы друг с другом. Наконец, в-четвертых, никакой продолжительный сбой связи не в состоянии нарушить передачу изменений. Дело в том, что тиражирование предполагает буферизацию потока изменений (транзакций); после восстановления связи передача возобновляется с той транзакции, на которой тиражирование было прервано.

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

7.8 Архитектура "клиент-сервер"

Распределенные системы - это системы "клиент-сервер". Существует по меньшей мере три модели "клиент-сервер":

  •  Модель доступа к удаленным данным (rda-модель)
  •  Модель сервера базы данных (dbs-модель)
  •  Модель сервера приложений (as-модель)

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

  •  Компонент интерфейса с пользователем
  •  Компонент управления данными (и базами данных в том числе)

а между ними расположено программное обеспечение промежуточного слоя (middleware), выполняющее функции управления транзакциями и коммуникациями, транспортировки запросов, управления именами и множество других. middleware - это ГЛАВНЫЙ компонент распределенных систем и, в частности, ddb-систем. Главная ошибка, которую мы совершаем на нынешнем этапе - полное игнорирование middleware и использование двухзвенных моделей "клиент-сервер" для реализации распределенных систем.

Существует фундаментальное различие между технологией "sql-клиент - sql-сервер" и технологией продуктов класса middleware (например, менеджера распределенных транзакций tuxedo system). В первом случае клиент явным образом запрашивает данные, зная структуру базы данных (имеет место так называемый data shipping, то есть "поставка данных" клиенту). Клиент передает СУБД sql-запрос, в ответ получает данные. Имеет место жесткая связь типа "точка- точка", для реализации которой все СУБД используют закрытый sql-канал (например, oracle sql*net). Он строится двумя процессами: sql/net на компьютере - клиенте и sql/net на компьютере-сервере и порождается по инициативе клиента оператором connect. Канал закрыт в том смысле, что невозможно, например, написать программу, которая будет шифровать sql- запросы по специальному алгоритму (стандартные алгоритмы шифрования, используемые, например, в oracle sql*net, вряд ли будут сертифицированы ФАПСИ).
В случае трехзвенной схемы клиент явно запрашивает один из сервисов (предоставляемых прикладным компонентом), передавая ему некоторое сообщение (например) и получает ответ также в виде сообщения. Клиент направляет запрос в информационную шину (которую строит tuxedo system), ничего не зная о месте расположения сервиса. Имеет место так называемый function shipping (то есть "поставка функций" клиенту). Важно, что для Клиента база данных (в том числе и ddb) закрыта слоем Сервисов. Более того, он вообще ничего не знает о ее существовании, так как все операции над базой данных выполняются внутри сервисов.
Сравним два подхода. В первом случае мы имеем жесткую схему связи "точка-точка" с передачей открытых sql-запросов и данных, исключающую возможность модификации и работающую только в синхронном режиме "запрос-ответ". Во втором случае определен гибкий механизм передачи сообщений между клиентами и серверами, позволяющий организовывать взаимодействие между ними многочисленными способами.
Таким образом, речь идет о двух принципиально разных подходах к построению информационных систем "клиент-сервер". Первый из них устарел и явно уходит в прошлое. Дело в том, что sql (ставший фактическим стандартом общения с реляционными СУБД) был задуман и реализован как декларативный язык запросов, но отнюдь не как средство взаимодействия "клиент-сервер" (об этой технологии тогда речи не было). Только потом он был "притянут за уши" разработчиками СУБД в качестве такого средства. На волне успеха реляционных СУБД в последние годы появилось множество систем быстрой разработки приложений для реляционных баз данных (visualbasic, powerbuilder, sql windows, jam и т.д.). Все они опирались на принцип генерации кода приложения на основе связывания элементов интерфейса с пользователем (форм, меню и т.д.) с таблицами баз данных. И если для быстрого создания несложных приложений с небольшим числом пользователей этот метод подходит как нельзя лучше, то для создания корпоративных распределенных информационных систем он абсолютно непригоден.
Для этих задач необходимо применение существенно более гибких систем класса middleware (tuxedo system, teknekron), которые и составляют предмет нашей профессиональной деятельности и базовый инструментарий при реализации больших проектов.

Заключение

Сегодня можно считать, что распределенные базы данных - тема достаточно локальная и далеко не так актуальная, как архитектура распределенных систем. В ddb-технологии за последние 2-3 года не было каких-либо существенных новаций (за исключением, быть может, технологии тиражирования данных). Можно считать, что в этой сфере информатики все более или менее устоялось и каких-либо революционных шагов не предвидится. Более интересное направление (включающее ddb) - архитектура, проектирование и реализация распределенных информационных систем. "Горячие" темы в этом направлении - системы с трехзвенной архитектурой, продукты класса middleware, объектно-ориентированные средства разработки распределенных приложений в стандарте corba. Их активное применение будет доминировать в отечественной информатике в ближайшие 3-5 лет и станет технологической базой реальных интеграционных проектов.
Мне кажется, что революция произойдет в архитектуре корпоративных информационных систем. Технологический взрыв в intertet, создание и супербурное развитие Всемирной паутины, технология java, неизбежно отразятся на организации инфраструктуры корпораций. На мой взгляд, очевидные преимущества гипертекстовой организации данных (гибкость, открытость, простота развития и расширения) перед жесткими структурами реляционных баз данных, по своей природе плохо приспособленными для расширения, предопределяют использование html в качестве одного из основных средств создания информационного пространства компании. Подход, опирающийся на гипертексты, позволяет без особых проблем интегрировать уже существующие информационные массивы, хранящиеся в базах данных. То, что сейчас называют intranet - это прообраз будущей корпоративной информационной системы.


 

А также другие работы, которые могут Вас заинтересовать

56525. Урок по алгебре форме игры «Счастливый случай» 208.5 KB
  Тригонометрические функции числового аргумента. Тригонометрические функции двойного и половинного аргумента. Обратные тригонометрические функции их определения. Какие явления напоминает график синусоиды или косинусоиды Составление кроссвордов друг другу...
56526. Урок Тригонометричні функції числового аргументу 268 KB
  Мета уроку: повторити, систематизувати й узагальнити знання учнів з теми; розвивати логічне мислення, пізнавальну діяльність, вміння застосовувати властивості тригонометричних функцій до побудови графіків...
56527. Розв’язування тригонометричних рівнянь 2.9 MB
  Розглянемо такі тригонометричні рівняння. Рівняння які зводяться до квадратних відносно тригонометричної функції. Рівняння які розв’язуються за допомогою рівності однойменних тригонометричних функцій. Лінійні рівняння відносно синуса і косинуса.
56528. Тригонометричні функції гострого кута прямокутного трикутника 83 KB
  Мета: формування поняття тригонометричних функцій гострого кута прямокутного трикутника дослідницько-евристичним методом; розвивати уміння учнів узагальнювати результати досліджень, спостережливість, прийоми аналізу і синтезу...
56529. Розв’язування прямокутних трикутників 519 KB
  Продовжте речення: Синус кута дорівнює відношенню протилежного катета до. гіпотенузи; cos 30o = ; Сума квадратів катетів дорівнює квадрату гіпотенузи; Прилеглий катет дорівнює добутку гіпотенузи на косинус кута...
56530. Трикутники. Сторони. Кути. Основа. Висота. Розпізнавання та креслення трикутників 276.5 KB
  Розпізнавання та креслення трикутників. Наочність: таблиця Трикутники малюнки трикутників Тип уроку: формування нових знань умінь і навичок Перебіг уроку. Види трикутників за кутами. Відшукування видів трикутників за допомогою косинця.
56531. Розв’язування трикутників 685 KB
  Мета уроку: формувати навички і вміння з розв’язування трикутників. Час виконання 1 Організаційний момент 7хв 2 Актуалізація опорних знань 7хв 3 Розв’язування вправ 16хв 4 Самостійна робота 10хв 5 Підсумок уроку 5хв...
56532. Сума кутів трикутника 197.5 KB
  Мета: Навчальна: Поглибити знання учнів про властивості трикутників Формувати уміння застосовувати вивчені властивості при розв’язуванні задач Провести діагностику засвоєння системи знань та умінь і її застосування для...
56533. ОЗНАКИ РІВНОСТІ ТРИКУТНИКІВ 743.5 KB
  У даній роботі представлена методична розробка уроків теми «Ознаки рівності трикутників», яка складається з 8-ми уроків та різнорівневої контрольної роботи. Розробка дає змогу подивитися на тему під іншим кутом зору.