Inf_comp_sys

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

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

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

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

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

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

Событие

Шина сообщений

Диаграмма 4

121

16.2Сервис-ориентированная архитектура

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

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

Многократное использование компонентов и возрастание гибкости — это основные причины популярности сервис-ориентированной архитектуры.

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

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

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

Таким образом, СОА предоставляет более высокий уровень абстракции нежели описанные выше способы интеграции приложений. Если раньше для взаимодействия систем компании с системами партнера необходимо было договориться о едином языке программирования, объектной модели, сервере приложений, то при использовании сервис-ориентированной архитектуры надо

122

согласовать лишь формат документов (схемы), и бизнес-правил работы с этими документами (Диаграмма 5).

Диаграмма 5

Рассмотрим серис-ориентированную архитектуру подробнее.

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

Всамом общем виде СОА предполагает наличие трех основных участников: провайдера сервиса, пользователя сервиса и реестра сервисов (Диаграмма 6). Взаимодействие участников выглядит достаточно просто: поставщик сервиса регистрирует свои сервисы в реестре, а потребитель обращается к реестру с запросом.

Следующие операции могут быть произведены в СОА:

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

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

Закрепление и вызов: После получения «описания» сервиса, пользователь может вызвать сам сервис, в соответствии с информацией в «описании».

123

Реестр сервисов

Диаграмма 6

Очень важно, что сервисы можно искать по типу, а не по имени или Unified Resource Locator(URL). Объект, который возвращается сервисом поиска, часто называют «посредником сервиса» (service proxy), поскольку он действует как дублер существующей где-то удаленно реализации сервиса. Посредник отвечает за все взаимодействия между приложением и реализацией сервиса.

Для использования сервиса необходимо следовать соглашению об интерфейсе для обращения к сервису - интерфейс должен не зависеть от платформы. СОА реализует масштабируемость сервисов - возможность добавления сервисов, а также их модернизацию. Поставщик сервиса и его потребитель оказываются несвязанными - они общаются с помощью сообщений. Поскольку интерфейс должен не зависеть от платформы, то и технология, используемая для определения сообщений, также должна не зависеть от платформы. Поэтому, как правило, сообщения являются Extended Markup Language(XML) документами, которые соответствуют XML-схеме.

Открытые стандарты, описывающие XML и Web-сервисы, позволяют применять СОА ко всем технологиям и приложениям, установленным в компании. Как известно, веб-сервисы базируются на широко распространенных и открытых протоколах: Hypertext Transfer Protocol(HTTP), XML, Universal Description, Discovery and Inegration(UDDI), Web Services Description Language(WSDL) и Simple Object Access Protocol(SOAP). Именно эти стандарты реализуют основные требования СОА: во-первых, сервис должен поддаваться динамическому обнаружению и вызову (UDDI, WSDL и SOAP), во-вторых, должен использоваться независящий от платформы интерфейс (XML). Наконец, HTTP обеспечивает функциональную совместимость.

Рассмотрим небольшой пример реализации услуг в некоторой компании с бизнес-процессами, обозначенными на диаграмме 7:

124

Диаграмма 7

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

Используя подход SOA, можно вынести бизнес-логику из приложения и преобразовать каждый логический блок в многократно-используемый сервис, как показано на диаграмме 8:

Диаграмма 8

125

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

Диаграмма 10

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

16.3Детализация уровня интеграции

16.3.1 Каналы обмена сообщениями

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

Диаграмма 11

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

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

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

127

Существуют несколько типов каналов сообщений, таких как канал «точкаточка», канал «публикация-подписка», канал типа данных и т.д. Рассмотрим какой шаблон и когда следует применять.

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

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

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

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

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

16.3.2 Канал «точка-точка»

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

128

Диаграмма 12

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

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

16.3.3 Канал «публикация-подписка»

Канал «публикация-подписка» функционирует следующим образом: у него есть один входной канал, который разбивается на несколько выходных каналов, по одному на каждого подписчика. Когда оповещение о событии публикуется в канале, канал «публикация-подписка» доставляет копию сообщения в каждый из выходных каналов. На каждом выходе канала есть только один подписчик, которому разрешается потреблять сообщение только один раз. Благодаря этому каждый подписчик получит сообщение только единожды, после чего потребленные копии сообщения исчезнут из соответствующих выходных каналов (Диаграмма 13).

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

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

129

Заказ 1

Подписчик

Заказ 1

Подписчик

Диаграмма 13

16.3.4 Канал типа данных

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

Диаграмма 14

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

130