4.4. Интеграционная шина как элемент построения инфраструктуры взаимодействия

Использование очередей сообщений в основе платформы интеграции приложений существенно усложняется при увеличении числа интегрируемых систем, каждая из которых может реализовывать очереди по-своему. Желание унификации взаимодействия привело к поискам обобщенной архитектуры интеграции. Когда появился метод межплатформного взаимодействия на основе web-сервисов, родился и новый подход к организации основы для интеграции – сервисная шина уровня предприятия (Enterprise Service Bus, ESB).

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

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

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

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

статическая и алгоритмическая маршрутизация сообщений;

доступ к данным из сторонних информационных систем с помощью готовых или специально разработанных адаптеров;

обработка и преобразование сообщений;

разнообразные механизмы контроля и управления (аудиты, протоколирование).

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

Для интеграции корпоративных приложений в современные BPMS активно применяются технологии сервисно-ориентированной архитектуры

(Service-Oriented Architecture, SOA). SOA – это подход к организации систем,

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

55

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

Основная задача SOA – обеспечение стандарта на интерфейсы и среду, в которой эти интерфейсы могут публиковаться и вызываться, а BPMS – обеспечение смысловой нагрузки и правила, согласно которым системы должны передавать друг другу информацию и управление. Наиболее распространенная реализация SOA – это спецификация web-сервисов, которые базируются на наборе открытых стандартов HTTP (транспорт), SOAP (обмен сообщениями), WSDL (описание интерфейсов) и UDDI (публикация и поиск сервисов). Назначение технологии web-сервисов состоит в обеспечении доступа к функциям прикладных систем через сеть вне зависимости от используемой платформы. В нашем контексте web-сервис можно определить как автономный стандартизированный программный компонент с описанными на языке XML внешними интерфейсами. Признанным отраслевым стандартом описания web-сервисов является основанный на XML

язык WSDL (Web Services Description Language). Стандарт WSDL позволяет описывать ключевые элементы интерфейса web-сервиса: его имя, поддерживаемые операции, исключения, входные и выходные данные; а также информацию, касающуюся вызова сервиса (связывания): протокол, способ передачи входных и выходных данных. Упрощенно принцип использования web-сервисов показан на рис. 29.

Рис. 29. Принцип использования web-сервисов

56

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

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

SOA – это концепция построения информационных систем путем представления их в виде сервисов, доступных для «наружного» использования, в том числе путем их интеграции с другими приложениями. SOA дает теоретическую возможность выбирать компоненты от разных поставщиков по принципу «лучший в классе» и объединять их в информационную систему предприятия [51].

57

5.РЕАЛИЗАЦИЯ НЕФУНКЦИОНАЛЬНЫХ ТРЕБОВАНИЙ

КПО ЭКСПЛУАТАЦИИ СЕТЕЙ СВЯЗИ

5.1.Многопользовательский доступ к данным

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

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

Методом контроля за транзакциями является ведение журнала, в котором фиксируются все изменения, совершаемые транзакцией в БД. Если во время обработки транзакции происходит сбой, транзакция откатывается – из журнала восстанавливается состояние БД на момент начала транзакции.

Стандарт SQL определяет, что транзакция начинается с первого SQLоператора, инициируемого пользователем или содержащегося в прикладной программе. Все последующие SQL-операторы составляют тело транзакции. Транзакция завершается одним из возможных способов [52]:

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

2.Оператор ROLLBACK прерывает транзакцию и отменяет все внесенные ею изменения;

3.успешное заверешение программы, инициировавшей транзакцию, означает успешное завершение транзакции (как использование COMMIT);

4.ошибочное завершение программы (или сетевого соединения) прерывает транзакцию (как ROLLBACK).

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

58

грязное чтение (Dirty Read) – транзакция Т1 модифицировала некий элемент данных. После этого другая транзакция Т2 прочитала содержимое этого элемента данных до завершения транзакции Т1. Если Т1 заврешается операцией ROLLBACK, то получается, что транзакция Т2 прочитала несуществующие данные;

неповторяемое (размытое) чтение (Non-repeatable or Fuzzy Read) –

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

фантом (фиктивные элементы) (Phantom) – транзакция Т1 прочи-

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

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

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

блокировка со взаимным доступом, называемая также S-блокиров-

кой (от Shared locks) и блокировкой по чтению;

монопольная блокировка (без взаимного доступа), называемая также X-блокировкой от (eXclusive locks) или блокировкой по записи. Этот режим используется при операциях изменения, добавления и удаления объектов.

При этом:

если транзакция налагает на объект X-блокировку, то любой запрос другой транзакции с блокировкой этого объекта будет отвергнут.

если транзакция налагает на объект S-блокировку, то:

−запрос со стороны другой транзакции с X-блокировокй на этот объект будет отвергнут;

−запрос со стороны другой транзакции с S-блокировокй этого объекта будет принят.

59

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

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

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

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

блокируются страницы (страница – фрагмент таблицы размером обычно 2–4 Кб, единица выделения памяти для обработки данных системой);

блокируются записи;

блокируются отдельные поля.

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

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

Распределенная база данных (DDB – distributed database) [53] – это совокупность логически взаимосвязанных баз данных, распределенных в компьютерной сети. Распределенная система управления базой данных определяется как программная система, которая позволяет управлять распределенной базой данных таким образом, чтобы ее распределенность была прозрачна для пользователей. Первая особенность такой БД – система состоит из (возможно, пустого) множества узлов приема запросов (query site) и непустого множества узлов данных (data site). Узлы данных обладают средствами для хранения данных, а узлы приема запросов – нет. В узлах приема запросов лишь выполняются программы, реализующие пользовательский интерфейс для доступа к данным, хранящимся в узлах данных. Вторая особенность состоит в том, что узлы логически представляют собой независимые компьютеры. Следовательно, у такого узла имеется собственная основная и внешняя память, установлена собственная операцион-

60