Введение

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

Схемы бизнес-структур

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

• Единая глобальная компания (Single Global Company) - Компания, предназначенная для ведения единого международного бизнеса, должна предлагать согласованные и унифицированные взаимодействия со своими глобальными бизнес-процессами клиентам, партнерам и поставщикам повсеместно, но также согласовываться с локальными поставщиками и учитывать различия, например, в законодательстве и налогообложении. Компания, желающая предлагать службы единообразно, независимо от месторасположения, может принять эту схему. Хотя многие компании стремятся к этому, для большинства в этом нет необходимости, и эта схема не является оптимальной.
• Сложная география (Multiple Geographies) - Компании могут быть распределены географически. Каждый регион функционирует независимо, но совместно для поддержки глобальной цели компании. Такая компания предлагает свои службы клиентам и взаимодействует с партнерами и поставщиками внутри конкретной страны или региона. Глобальные обязательства - как исключение. Каждая региональная организация ответственна за соответствие требованиям локального законодательства. Это традиционная модель для многонациональных компаний.
• Несколько бизнес-подразделений (Multiple Business Divisions) - Компании могут разделять свои операции по товару, службе или функции, предоставляя каждому подразделению автономию. Эффективность бизнеса часто может быть реализована при помощи общих базовых служб - например, управление клиентами. Автономные базовые службы, которые отличаются между собой или дублируются, потенциально приводят к нежелательным затратам. Банки часто подстраивают эту модель для отдельных подразделений, работающих с индивидуальными клиентами, кредитными картами и ипотечными кредитами.
• Сеть магазинов/филиалов (Store/Branch Network) - Компании с сетью филиалов часто организовывают интеграционную функциональность, процессы и возможности под централизованным или региональным управлением. Они различаются по своим потребностям при разрешении изменения служб филиалов. Централизованная инфраструктура, с которой связаны все филиалы, и из которой эти филиалы управляются, является характерной особенностью этой модели. Этой модели придерживаются многие розничные компании и финансовые учреждения с филиалами.
• Иерархическая (Hierarchical) - В иерархической организации различные бизнес-подразделения определяют и выполняют свои операции автономно, возможно, с использованием некоторых централизованных служб. Или (применяя аналогичную модель с большей степенью детализации) подразделение может предоставлять службы своим локальным отделам, которые, в свою очередь, определяют и выполняют свои собственные бизнес-процессы и службы, составленные из этих служб.

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

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

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

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

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

В начало

Модели и схемы руководства

Фундаментом успешности SOA является модель руководства. Гибкость бизнеса зависит от того, как управляются и контролируются предоставляемые бизнесом службы. Обычно различные подразделения организации имеют свое собственное административное управление и руководство.

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

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

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

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

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

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

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

• Единое руководство (Sole Governance) - Взаимодействие может происходить полностью в бизнес-области, которая обеспечивает руководство им и не доступна извне. Например, ответственность за завод-изготовитель может полностью лежать на части бизнеса, работающего в конкретной стране. В этом случае нет специальных условий для руководства.
• Локальное руководство (Local Governance) - Взаимодействие (см. рисунки 1-3), происходящее полностью внутри одного подразделения, делается доступным другим бизнес-областям при помощи спецификации интерфейса. За интерфейсом реализация полностью управляется владельцем. Например, производственное оборудование может выполнять заказы, размещенные клиентами, которые взаимодействуют с другими подразделениями компании.

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

• Федеративное руководство (Federated Governance) - Каждое подмножество взаимодействий, распространяющееся на несколько подразделений, управляется соответствующим подразделением; эти подмножества сотрудничают при помощи согласованных интерфейсов. Например, взаимодействием могут быть переговоры между подразделением, принимающим заказ, и фабрикой, его выполняющей.

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

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

В начало

Схемы ESB-топологии

В данном разделе рассматриваются различные схемы ESB-топологии с точки зрения управления, руководства, виртуализации служб и требований к развертыванию. Различные ESB-топологии представлены в руководстве IBM "Схемы: Интегрирование корпоративных служебных шин в сервис-ориентированную архитектуру". Эта статья развивает предыдущую работу, отображая каждую из описанных в предыдущем разделе моделей организации бизнеса в соответствующую SOA и применяя затем соответствующую ESB-топологию.

Также обсуждается влияние каждой ESB-топологии на промежуточные схемы и роли пользователей [см. статью "Программная модель SOA для реализации Web-служб, Часть 10: роли пользователей SOA" (developerWorks, февраль 2006)]. Для единой ESB это было описано в четвертой части серии статей "Введение в IBM Enterprise Service Bus" (developerWorks, июль 2005). В существующей литературе описываются одиночные ESB, топологии с одним пространством имен, в которых каждый провайдер видим каждому инициатору запроса через гетерогенную, управляемую централизованно среду (см. публикации, перечисленные в разделе "Ресурсы"). Эта статья развивает предыдущие работы, анализируя новые схемы, формируемые несколькими ESB-сегментами.

Единая логическая ESB

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

Соответствующей моделью ESB является "единая логическая ESB" (Single Logical ESB), которая имеет много общих характеристик с моделью "единая ESB": одно пространство имен, все провайдеры видимы всем инициаторам запроса. Однако организация глобального доступа к службам (независимого от месторасположения инициатора запроса) ставит следующие задачи:

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

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

Пользовательские роли в ESB и SOA затрагиваются следующим образом:

• Экономист-аналитик (Business Analyst) устанавливает бизнес-требования и процессы по регионам, поскольку глобальная унификация является признаком данного подхода. Хорошее качество спецификаций служб, сформулированных с точки зрения бизнеса, помогает проектировщику оценить, где и как предоставить службы.
• Самая трудная работа разработчика решений (Solution Architect) касается компонентов, поддерживающих ESB-топологию. Решения, влияющие на управление данными и целостность данных, должны быть основаны на прецедентах использования (use cases). Проект должен удовлетворять требованиям качества обслуживания (quality-of-service) и нефункциональным требованиям без ограничений в месторасположении инициаторов запроса службы.
• Администратор решений (Solution Administrator) должен собрать и развернуть решения так, чтобы каждая из физических ESB предоставляла одинаковую функциональность способом, поддерживающим восстановление после отказа в случае недоступности физической ESB. Также должны быть унифицированы функции защиты.
• Оператор (Operator) должен быть способен выполнять мониторинг физической маршрутизации и соответствующего поведения запросов службы для управления и соответствия ожидаемым уровням обслуживания.

Схемы с посредниками похожи на единую ESB, за исключением:

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

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

ESB прямого подключения (Directly Connected ESB) с единым реестром

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

Этим бизнес-моделям соответствуют "ESB прямого подключения" (рассматриваемая в этом разделе) и "ESB через посредника" (рассматриваемая в следующем разделе).

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

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

Эта схема поддерживает виртуализацию служб следующим образом: для вызова служб другого подразделения компании вы определяете "заглушку" (stub) службы на локальной ESB, инкапсулируя операцию поиска в реестре. Таким образом (с соответствующим управлением правами доступа и политикой в двух ESB), инициатор запроса одного подразделения может вызывать службы, предоставляемые другим подразделением, напрямую соединяя две ESB.

Давайте рассмотрим, как эта схема влияет на пользовательские роли в ESB и SOA:

• Экономист-аналитик (Business Analyst) концентрируется на отображении границ инфраструктуры ESB на бизнес-подразделения или географические регионы, а также на управлении бизнес-процессами, выходящими за границы и выполняющимися по частям. Вычисление основных показателей производительности или мониторинг процессов от начала до конца могут потребовать метрики от нескольких подразделений.
• Разработчик решений (Solution Architect) обдумывает, как максимизировать повторное использование IT-ресурсов в различных подразделениях. Должны быть определены взаимодействия между ESB (включая политику и защиту), а службы и структуры данных должны быть отображены для совместного использования служб подразделениями.
• Когда разработчик интеграции (Integration Developer) компонует оконечные точки службы в решения, строгое соблюдение спецификаций разработчика решений облегчает их использование другими подразделениями.
• Администратор решений (Solution Administrator) компонует решения, развертывает их в соответствующие ESB и импортирует определения служб в общий реестр, применяя необходимые параметры защиты и управления доступом с точки зрения предприятия в целом.
• Оператор (Operator) концентрируется на мониторинге и управлении использованием служб между подразделениями. Бизнес-процессы и транзакции, охватывающие несколько ESB, требуют агрегирования служб инфраструктуры.

Схемы с посредником отличаются от единой ESB в следующем:

• Модернизация системы и пользовательские посредники могут потребовать доступа к (или локальных копий) данным из других регионов, например, данным подразделений провайдера службы.
• Схема "Монитор" (Monitor) может быть использована на всех ESB, вовлеченных в обслуживание запроса.

ESB прямого подключения с несколькими реестрами

Вариант схемы ESB прямого подключения использует один реестр на каждую ESB (возможно, дополненные центральным реестром, поскольку руководство является централизованным). Без центрального реестра каждое подразделение компании должно определить и соответствовать требованиям для служб, предоставляемых другим подразделениям. Любой вариант требует внимательного рассмотрения: 1) как метаданные служб реплицируются, синхронизируются, разбиваются, преобразовываются и т.д. между несколькими реестрами; 2) как нефункциональные характеристики (не только функции защиты, но и производительность, надежность, транзакциональность и т.д.) поддерживаются при взаимодействиях службы с несколькими ESB.

ESB с посредником

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

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

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

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

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

Задачи для пользовательских ролей SOA соответствуют задачам в схеме "ESB прямого подключения", за исключением:

• Разработчик интеграции (Integration Developer) может дополнительно разработать посредников для общих форматов сообщений и политик.
• Задачи оператора (Operator) такие же, за исключением того, что мониторинг и управление централизуется вокруг вызовов служб посредником.

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

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

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

ESB с концентратором и спицами (Hub and Spokes ESB)

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

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

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

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

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

Пользовательские роли в SOA следующие:

• Экономист-аналитик (Business Analyst) концентрируется на архитектурном размещении центральных процессов и служб, которые поддерживают активность филиалов, и на способе их доступа к необходимым данным. Любые взаимодействия филиал-филиал производятся через центр. Экономисты-аналитики в филиалах ответственны за дополнительные локальные требования и варианты.
• Разработчик решений (Solution Architect) определяет взаимодействие между филиалами и центром, включая безопасность, политику, мониторинг и управление. Некоторые из вопросов касаются защищенного пользовательского доступа в филиалах, прерванных операций, управления на уровне службы и отложенной синхронизации данных. Пропускная способность может ограничить производительность или повлиять на способность перемещения данных в поддержку выполнения локальной службы. Разработчик определяет также механизмы для создания локальных служб или изменения центральных служб.
• Разработчик интеграции (Integration Developer) согласовывается со спецификациями для обеспечения возможности взаимодействий филиал-концентратор и концентратор-филиал, включая генерирование специфических событий для мониторинга из посредников.
• Администратор решений (Solution Administrator) объединяет решения и гарантирует координированное развертывание в центральной ESB и по всем филиалам. Пользовательский доступ в филиалах часто управляется централизовано. Изменения и дополнения служб требуют локального администрирования и также должны быть защищены.
• Оператор (Operator) выполняет мониторинг ESB концентратора и филиалов, поддерживая доступность при несоответствии уровней обслуживания или прерывании и восстановлении соединения с филиалами; также возможны локальные операции в филиалах.

Схемы с посредником похожи на схему единой ESB, за исключением:

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

Наложенная ESB (Imposed ESB)

Схема наложенной ESB, более экстремальной версии ESB с концентратором и спицами, подходит для модели бизнеса "Сеть магазинов/филиалов", в которой руководство всеми службами осуществляется централизованно. Центральный орган или региональный офис предоставляет все IT-службы (с маленькими инвестициями в IT-квалификацию филиалов или вообще без них), поскольку локальная автономия запрещена. Как и в схеме с концентратором и спицами, службы могут быть развернуты в филиалах для поддержки операций, требующих соединения с концентратором, с возможностью автономной нейтрализации неисправности.

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

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

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

В начало

Усложненное использование реестра служб

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

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

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

Пользовательские роли SOA:

• Разработчик решений (Solution Architect) определяет механизмы для развертывания служб и управления реестром, разрешающие оптимальную маршрутизацию запросов, охватывающих несколько ESB.
• Администратор решений (Solution Administrator) при развертывании и управлении службами каскадирует записи с реестра самого верхнего уровня до других реестров при необходимости.

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

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

В начало

Мониторинг сложной ESB-топологии

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

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

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

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

ESB является посредником между производителями и потребителями событий. Такая схема может потребовать выборочного распространения событий через сегменты ESB по ESB-топологии. При проектировании событий в SOA примите во внимание следующее:

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

В начало

Заключение

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

В начало

Благодарности

Авторы хотели бы выразить благодарность Марку Томасу Шмидту (Marc-Thomas Schmidt), Полу Вершурену (Paul Verschueren) и Рику Робинсону (Rick Robinson) за их вклад в статью.

Ресурсы

Научиться

• Оригинал статьи "Choose an ESB topology to fit your business model".
  
  
• Отличное введение в ESB приводится в статье "Программная модель SOA для реализации Web-служб, часть 4: Введение в IBM Enterprise Service Bus" (developerWorks, июль 2005).
  
  
• Узнайте о SOA и о том, как она влияет на IT-эффективность, из статьи "Улучшение планирования SOA-проектов" (developerWorks, июль 2004).
  
  
• Дополнительная информация о моделях руководства приведена в статье "Вариант SOA-руководства" (developerWorks, август 2005).
  
  
• Прочтите следующие книги серии IBM Redbooks:
  
  • "Шаблоны: Реализация SOA с использованием Enterprise Service Bus"
  • "Шаблоны: Интегрирование Enterprise Service Bus в сервис-ориентированную архитектуру"
  • "Шаблоны: SOA с использованием Enterprise Service Bus в WebSphere Application Server V6"
  
  
• Шаблоны IBM для e-business.
  
  
• Следите за текущими конференциями developerWorks, проводимыми ведущими техническими экспертами IBM.
  
  

Обсудить

• Примите участие в блогах developerWorks и подключайтесь к сообществу developerWorks.
  
  

Об авторах

Крис Нотт (Chris Nott) - специалист по вычислительной технике, консультант IBM Software Group, Великобритания. Имеет 15-летний опыт разработки программного обеспечения, архитектурных решений и технического предпродажного консультирования. В настоящее время занимается бизнес-интеграцией и обладает хорошей подготовкой в области проектирования реляционных систем и технологии баз данных. Он написал много статей по бизнес-интеграции и Enterprise Service Bus. Имеет степень бакалавра математики от University of Durham и зарегистрирован в UK как дипломированный инженер.

Марсиа Стоктон (Marcia Stockton) - старший сотрудник технического отдела IBM Software Group. Она руководит рабочей группой Software Group Architecture Board, занимающейся определением и развитием программной модели SOA, и является соавтором книги "Реализация SOA". Марсиа обладает также статусом IBM Master Inventor, имея более 70 патентов по программному обеспечению и сетевым технологиям. Ее 18-летняя карьера в IBM включает руководящие роли в разработке высокопроизводительной маршрутизации, развитых сетевых систем с равноправными узлами, технологии Bluetooth, IBM WebSphere Edge Server и Broadband Networking, а также авторство многочисленных работ и статей. Она является старшим сотрудником IEEE. C 2001 она выполняет эти обязанности удаленно, откуда-то из Сьерра-Невады.

Оценить эту статью

Комментарии

В начало

Содержание

• Введение
• Схемы бизнес-структур
• Модели и схемы руководства
• Схемы ESB-топологии
• Усложненное использование реестра служб
• Мониторинг сложной ESB-топологии
• Заключение
• Благодарности
• Ресурсы
• Об авторах
• Комментарии