Реализация SOA-инфраструктуры на базе сервисной шины предприятия

Аппаратно-программную платформу, реализующую инфраструктуру КИС с SOA-архитектурой называют сервисной шины предприятия (ESB). ESB-шина образует однородную среду информационного взаимодействия внутрикорпоративных (intranet-) и внешних (extranet-) приложений и является фундаментом для их интеграции (рис. 2). Она определяет, кем, где, каким образом, и в каком порядке должны обрабатываться запросы на сервисное обслуживание времени выполнения.

Рис. 2. Общая схема ESB-шины

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

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

Рис. 3. Топология «одна шина, один сервер»

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

Рис. 4. Топология «одна шина, несколько серверов»

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

Шина ESB действует как логический, распределенный, транзакционный и управляющий сообщениями уровень для связывания приложений, разнотипных данных и других служб, которые распределены по вычислительной сети предприятия. Базовая роль магистрали для работы с синхронными и асинхронными сообщениями дополняется логическими возможностями трансформации и маршрутизации данных, что обеспечивает надежную передачу сообщений. ESB позволяет разработчикам вызывать и применять бизнес-функции, входящие в компоненты КИС, независимо от API (это интерфейс программирования, интерфейс создания приложений) или протокола, поскольку компоненты используются как службы, интерфейс которых имеет стандартное описание на языке Web Service Descrition Language (WSDL).

От развертывания систем на базе SOA пользователи получают следующие преимущества:

ü Возможность взаимодействия корпоративных приложений с широким кругом программных продуктов, реализованных на различных программно аппаратных платформах;

ü Упрощение и ускорение процесса разработки бизнес-приложений ‑ приложения строятся, как система взаимосвязанных компонентов и при этом используются наиболее подходящие компоненты из имеющихся на рынке;

ü Легкая интеграция новых функций в действующую корпоративную систему;

ü Возможность гибкого изменения и постоянного совершенствования бизнес-процессов предприятия;

ü Оптимизация процессов управления предприятием за счет упрощения процедур объединения информационных потоков и бизнес-процессов;

ü Поэтапное совершенствование корпоративной информационной инфраструктуры без привлечения крупных инвестиций.

Предполагается, что в будущем практически все взаимодействие приложений как в рамках одной информационной системы, так и между системами отдельных участников бизнес-процесса, будет осуществляться с использованием механизма web-cервисов, так что достаточно критическими становятся вопросы согласованной работы и управления этими сервисами. Для описания согласованной работы сервисов были предложены специальные термины – "хореография" и "оркестровка". При этом если хореография определяет взаимодействие различных участников с использованием сервисов, то оркестровка описывает взаимодействие сервисов в рамках одного бизнес-процесса, в частности, с использованием языка типа BPEL.

 

 

Этапы перехода к СОА

На предприятии переход к СОА состоит из трех этапов:

ü Создание сервисов. Подготовка всех существующих приложений к взаимодействию в рамках новой архитектуры и поиск или разработка недостающих сервисов.

ü Построение инфраструктуры сервис-ориентированной архитектуры.

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

 

Создание сервисов

Создание сервисов может происходить различными способами:

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

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

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

ü Осуществление поиска готовых сервисов. Сервис может быть уже доступен. Все больше и больше коробочных приложений предоставляют интерфейсы взаимодействия с ними, как с веб-сервисами. Большинство систем уровня предприятия (ERP, CRM) предоставляют программные интерфейсы
приложений (API) для веб-сервисов;

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

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