Управление SOA – путь к совершенству. Сервис-ориентированная архитектура: от концепции к применению

Обзор терминологии SOA

Часть 1. Сервис, архитектура, управление и бизнес-термины

Бертран Портье (Bertrand Portier)
Опубликовано 25.06.2008

Серия контента:

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

Организационное замечание

Перечисленные ниже термины не выстроены по алфавиту, равно как и по степени важности. Они организованы скорее в блочном стиле. Мы начинаем с "сервиса", поскольку это фундаментальное понятие в рамках SOA. На этом понятии мы строим определения таких терминов, как "архитектура", "управление" и "бизнес". Во многих случаях мы разбиваем объемные термины на их составные компоненты.

Сервис

Сервисы являются, несомненно, сердцем сервис-ориентированной архитектуры: сам термин сервис широко используется. Однако разные люди понимают его по-разному, а потому вопрос "Что такое сервис?" часто приводит к долгим спорам. Мне приходилось слышать, как люди разговаривают о бизнес-задачах, бизнес-сервисах, функциях приложений, технических сервисах и сервисах из области инфраструктуры. Позвольте, я дам вам определение, основанное на IBM Rational® Method Composer Plug-in for SOA Governance и на IBM Rational® Unified Process for Service-Oriented Architecture. Дополнительную информацию вы найдете в .

"Сервис – это видимый ресурс, выполняющий повторяющуюся задачу и описанный внешней инструкцией".

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

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

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

Также важно учитывать, что не все является сервисом. Есть такие ИТ-функции, которые размещать в качестве сервисов смысла нет. Такие аналитические техники, как IBM Service-Oriented Modeling and Architecture (SOMA), помогают определять соответствие сервисов перечисленным выше идеям. Все эти моменты (включая все выделенные термины из данного раздела) мы подробно рассмотрим в данной статье.

Архитектура

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

На форуме Open Group Architecture Forum (TOGAF) есть два определения архитектуры в зависимости от контекста:

1. "Формальное описание или подробный план системы на уровне компонентов для руководства в процессе ее создания.
2. Структура компонентов, их взаимосвязи, принципы и направления развития, определяющие их разработку и эволюцию."

Эти два определения критически важны для понимания "A" (архитектуры) из аббревиатуры SOA. Заглянув глубже, мы видим также, что архитектура необходима для следующего:

• Разработка и моделирование на разных уровнях абстракции
• Отделение инструкции от реализации
• Построение гибких систем
• Проверка на соответствие бизнес-требованиям
• Анализ объема изменений при появлении новых требований
• Проверка на соответствие правилам

Архитектура предприятия

Вот определение из Википедии:

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

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

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

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

Ориентация на сервисы

Как написано в техническом обзоре IBM SOA foundation, "... ориентация на сервисы – это путь интеграции бизнеса как набора связанных сервисов." Больше информации об IBM SOA foundation вы найдете в .

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

Эталонная модель SOA foundation

IBM SOA foundation содержит эталонную модель SOA, показанную на рисунке 1, в которой отображены ключевые характеристики, необходимые для поддержки сервис-ориентированной архитектуры.

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

Рисунок 1. Эталонная модель SOA foundation

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

В IBM SOA foundation SOA определена следующим образом:

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

SOA обладает следующими характеристиками:

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

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

Структура решений SOA, показанная на рисунке 2, представляет собой эталонную модель SOA, отражающую концептуальное (высокоуровневое) устройство решений SOA.

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

Она не зависит от технологий, на которых построена. Как вы увидите в разделе "Модельно-управляемая архитектура" (Model-Driven Architecture - MDA) во второй статье данной серии, это разделение важно.

Рисунок 2. Структура решений SOA

Структура состоит из 5 функциональных слоев (снизу вверх):

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

Управление

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

Этот раздел содержит определения из IBM Rational Method Composer Plug-in for SOA Governance. Здесь определяются термины "управление", "ИТ-управление", "SOA-управление", а также определяется разница между управлением, руководством и соответствием. Тут же описываются проблемы, стоящие перед SOA-управлением. Более подробную информацию о Rational Method Composer вы найдете в .

Управление

"Под управлением мы подразумеваем:

• Установление цепочек ответственности, полномочий и связей, чтобы уполномочить людей (права на принятие решений)
• Установление механизмов для измерений, расчетов и контроля с тем, чтобы люди могли выполнять свои обязанности в рамках своей ответственности

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

Частью любого управленческого решения является соответствие организационным правилам соответствия. Соответствие - это документированное доказательство того, что управление имеется и реализуется: решения документируются, а правила принятия решений соблюдаются."

ИТ-управление

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

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

SOA-управление

"SOA-управление – это надстройка над ИТ-управлением, ориентированная на сервисы и прочие продукты жизненного цикла SOA."

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

"SOA-управление предназначено для решения следующих проблем:

• Какие новые организационные должности и структуры нужны для идентификации, разработки и совместного использования сервисов?
• Какие метрики поддерживают вложение средств, обслуживание, жизнеспособность и совместное использование сервисов?
• Как бизнесу решить вопрос об инвестициях в создание и обслуживание сервисов?
• Что такое зрелость производства в области сервис-ориентированности?
• Какие необходимы образование, обучение или наставничество?"

Жизненный цикл

Жизненный цикл сервиса

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

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

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

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

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

В определении жизненного цикла SOA IBM SOA foundation отмечает четыре фазы:

• Модель состоит из бизнес-анализа и разработки (требования, процессы, цели, ключевые показатели продуктивности) и ИТ-анализа и разработки (определение и спецификация сервисов).
• Сборка состоит из программирования сервисов и построения сложных приложений.
• Размещение состоит из размещения приложений и средств времени исполнения, таких как Enterprise Service Buses (ESB).
• Руководство состоит из поддержки операционной среды, мониторинга производительности сервисов и слежения за соблюдением сервисных политик.

Определенные выше SOA-управление и процессы поддерживают эти четыре фазы. Это отображено на рисунке 3.

Рисунок 3. Жизненный цикл SOA

Бизнес

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

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

Ориентация на бизнес

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

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

Компонентное представление бизнеса

сайтponent Business Model® - стратегический метод, позволяющий компаниям фокусироваться на своих ключевых сферах деятельности – на том, чем компания отличается от своих конкурентов, на отслеживании потребления ресурсов и установлении лучшей связи бизнеса со сферой ИТ. В вы найдете дополнительную информацию о Component Business Model. С помощью и благодаря ориентации на сервисы достигается интеграция и взаимодействие этих компонентов бизнеса, а также гибкость, благодаря которой можно проводить аутсорсинг компонентов: у каждого из компонентов бизнеса есть своя уникальная цель, а сообщаются они между собой посредством набора бизнес-сервисов, которые они поставляют другим компонентам либо получают от других компонентов. Это можно рассматривать как часть "бизнес-архитектуры".

Бизнес-моделирование

Бизнес-моделирование определяется IBM Rational Unified Process® следующим образом:

"Дисциплина Rational Unified Process Business Modeling предоставляет точное руководство для описания с помощью набора подходов и техник, на разных уровнях формализации "текущего" или "желаемого" бизнеса".

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

SOA – долговременная стратегия реорганизации бизнеса и ИТ-систем, цель которой - быстрое реагирование на перемены. В есть ссылка на журнал IBM Systems (том 44, номер 4), рассказывающий о SOA, в котором вы найдете более подробное рассмотрение связанных с бизнесом сторон сервис-ориентированного мышления.

Бизнес-процесс

Бизнес-процесс – это последовательность действий, дающая полезный результат.

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

Бизнес-деятельность и задачи

Бизнес-деятельность и задачи – это элементы, которые, будучи связаны, образуют бизнес-процессы.

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

Моделирование бизнес-процессов

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

Моделирование бизнес-процессов дает не только визуальное представление, но и позволяет позже связать элементы модели бизнес-процесса с элементами ИТ – в том случае, если осуществляется в инфраструктуре, которая работает с лежащими в основе процессов метаданными.

Задачи для людей

Довольно часто в процессах требуется человеческое вмешательство (например, утверждение командировки или кредита). Такие задачи при моделировании бизнес-процесса определяются как ручные, и для каждой задачи назначается определенная роль. После размещения для выполнения процессов SOA потребуется поддержка задач, выполняемых людьми. Такие продукты, как, например, IBM WebSphere Process Server, предоставляют пользователям списки ожидающих их задач для людей. При их комбинировании с такими продуктами, как IBM WebSphere Portal и Lotus Sametime, пользователи также могут сотрудничать между собой и оповещать систему о принятых ими решениях, чтобы система могла продолжать выполнение процессов. Этот человеческий фактор критически важен для успеха SOA.

BPEL

IBM, Microsoft и другие компании участвовали в разработке языка Business Process Execution Language (BPEL) for Web services specification (язык выполнения бизнес-процессов для создания спецификаций Web-сервисов), являющегося средством формального описания бизнес-процессов и протоколов взаимодействия.

Отрасли

В разных сферах деятельности и отраслях бизнес-процессы могут иметь свою специфику, как, например, в страховании. Отраслевые бизнес-процессы определяются промышленными консорциумами. Например, TeleManagement Forum определяет enhanced Telecom Operations Map (eTOM) для телекоммуникационной отрасли. Кроме того, компании, чтобы выделиться среди конкурентов, могут внедрять свои собственные бизнес-процессы, основанные на проверенных моделях, таких как IBM Industry Models. В приведена ссылка на IBM Insurance Application Architecture (IAA), которая является примером IBM Industry Models.

Управление бизнес-процессами

Управление бизнес-процессами (Business Process Management - BPM) занимается полным жизненным циклом бизнес-процессов с целью повышения их эффективности, гибкости и управляемости.

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

Заключение

В этой первой части серии статей, посвященных терминологии SOA, мы определили такие основные термины SOA, как сервис, SOA, а также связь SOA с архитектурой. Мы определили два термина - жизненный цикл сервиса и SOA-управление, - которые являются основополагающими элементами SOA. Кроме того, мы обсудили связь SOA с бизнесом и описали бизнес-процессы. И это только начало. В следующих статьях мы определим термины SOA, связанные с ИТ-дизайном, разработкой, рабочим процессом и управлением. Так что оставайтесь на связи с developerWorks!

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

Я хотел бы поблагодарить моих коллег из IBM, которые внесли большой вклад в сервис-ориентированную архитектуру и описанные в статье идеи. Особую благодарность выражаю Ричарду Джонсону (Richard D. Johnson) и Стиву Киндеру (Steve Kinder) за рецензию на эту статью.

Сервис-ориентированная архитектура (service-oriented architecture, SOA) придумана в конце 1980-х. Она берёт своё начало в идеях, изложенных в CORBA, DCOM, DCE и других документах. О SOA написано много, есть несколько её реализаций. Но, по сути, SOA можно свести к нескольким идеям, причём архитектура не диктует способы их реализации:

• Сочетаемость приложений, ориентированных на пользователей.
• Многократное использование бизнес-сервисов.
• Независимость от набора технологий.
• Автономность (независимые эволюция, масштабируемость и развёртываемость).

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

В этой статье я рассмотрю следующие паттерны, относящиеся к SOA:

• Общая архитектура брокера объектных запросов (CORBA).
• Веб-сервисы.
• Очередь сообщений.
• Сервисная шина предприятия (ESB).
• Микросервисы.

Общая архитектура брокера объектных запросов (CORBA)

В 1980-х началось активное использование корпоративных сетей и клиент-серверной архитектуры. Возникла потребность в стандартном способе взаимодействия приложений, которые созданы с использованием разных технологий, исполняются на разных компьютерах и под разными ОС. Для этого была разработана CORBA. Это один из стандартов распределённых вычислений, зародившийся в 1980-х и расцветший к 1991 году.

Стандарт CORBA был реализован несколькими вендорами. Он обеспечивает:

• Не зависящие от платформы вызовы удалённых процедур (Remote Procedure Call).
• Транзакции (в том числе удалённые!).
• Безопасность.
• События.
• Независимость от выбора языка программирования.
• Независимость от выбора ОС.
• Независимость от выбора оборудования.
• Набор данных через язык описания интерфейсов (Interface Definition Language, IDL).

Сегодня CORBA всё ещё используется для разнородных вычислений. Например, он до сих пор является частью Java EE , хотя начиная с Java 9 будет поставляться в виде отдельного модуля .

Хочу отметить, что не считаю CORBA паттерном SOA (хотя отношу и CORBA, и SOA-паттерны к сфере распределённых вычислений). Я рассказываю о нём здесь, поскольку считаю недостатки CORBA одной из причин возникновения SOA.

Принцип работы

Сначала нам нужно получить брокер объектных запросов (Object Request Broker, ORB), который соответствует спецификации CORBA. Он предоставляется вендором и использует языковые преобразователи (language mappers) для генерирования «заглушек» (stub) и «скелетов» (skeleton) на языках клиентского кода. С помощью этого ORB и определений интерфейсов, использующих IDL (аналог WSDL), можно на основе реальных классов генерировать в клиенте удалённо вызываемые классы-заглушки (stub classes). А на сервере можно генерировать классы-скелеты (skeleton classes), обрабатывающие входящие запросы и вызывающие реальные целевые объекты.

Вызывающая программа (caller) вызывает локальную процедуру, реализованную заглушкой.

1. Заглушка проверяет вызов, создаёт сообщение-запрос и передаёт его в ORB.
2. Клиентский ORB шлёт сообщение по сети на сервер и блокирует текущий поток выполнения.
3. Серверный ORB получает сообщение-запрос и создаёт экземпляр скелета.
4. Скелет исполняет процедуру в вызываемом объекте.
5. Вызываемый объект проводит вычисления и возвращает результат.
6. Скелет пакует выходные аргументы в сообщение-ответ и передаёт его в ORB.
7. ORB шлёт сообщение по сети клиенту.
8. Клиентский ORB получает сообщение, распаковывает и передаёт информацию заглушке.
9. Заглушка передаёт выходные аргументы вызывающему методу, разблокирует поток выполнения, и вызывающая программа продолжает свою работу.

Достоинства

• Независимость от выбранных технологий (не считая реализации ORB).
• Независимость от особенностей передачи данных/связи.

Недостатки

• Независимость от местоположения : клиентский код не имеет понятия, является ли вызов локальным или удалённым. Звучит неплохо, но длительность задержки и виды сбоев могут сильно варьироваться. Если мы не знаем, какой у нас вызов, то приложение не может выбрать подходящую стратегию обработки вызовов методов, а значит, и генерировать удалённые вызовы внутри цикла. В результате вся система работает медленнее.
• Сложная, раздутая и неоднозначная спецификация : её собрали из нескольких версий спецификаций разных вендоров, поэтому (на тот момент) она была раздутой, неоднозначной и трудной в реализации.
• Заблокированные каналы связи (communication pipes) : используются специфические протоколы поверх TCP/IP, а также специфические порты (или даже случайные порты). Но правила корпоративной безопасности и файрволы зачастую допускают HTTP-соединения только через 80-й порт, блокируя обмены данными CORBA.

Веб-сервисы

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

И для решения этих задач в конце 1990-х начали появляться веб-сервисы.

• Нужен был надёжный канал связи , поэтому:
  • HTTP стал по умолчанию работать через порт 80.
  • Для обмена сообщениями начали использовать платформо-независимый язык (вроде XML или JSON).
• Нужно было уменьшить количество удалённых обращений , поэтому:

[Веб-]сервисы можно публиковать, находить и использовать стандартным образом вне зависимости от технологий.
- Microsoft 2004,

Благодаря микросервисам мы перешли в парадигме SOA от удалённого вызова методов объекта (CORBA) к передаче сообщений между сервисами.

Но нужно понимать, что в рамках SOA веб-сервисы - не просто API общего назначения, всего лишь предоставляющие CRUD-доступ к базе данных через HTTP. В каких-то случаях эта реализация может быть полезной, но ради целостности ваших данных необходимо, чтобы пользователи понимали лежащую в основе реализации модель и соблюдали бизнес-правила . SOA подразумевает, что веб-сервисы являются ограниченными контекстами бизнес-субдоменов (business sub-domain) и отделяет реализацию от решаемых веб-сервисами задач.

С точки зрения технологий SOA не просто сервисная архитектура, а набор политик, методик и фреймворков, благодаря которым мы предоставляем и получаем нужные сервисы.
- Microsoft 2004, Understanding Service-Oriented Architecture

Достоинства

• Изолированность контекстов доменов (Domain contexts).

Недостатки

• Синхронный обмен сообщениями может перегрузить системы.

Очередь сообщений

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

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

• Запрос/Ответ

  • Клиент шлёт в очередь сообщение, включая ссылку на «разговор» («conversation» reference) . Сообщение приходит на специальный узел, который отвечает отправителю другим сообщением, где содержится ссылка на тот же разговор , так что получатель знает, на какой разговор ссылается сообщение, и может продолжать действовать. Это очень полезно для бизнес-процессов средней и большой продолжительности (цепочек событий, sagas ).
• Публикация/Подписка
  • По спискам
    Очередь поддерживает списки опубликованных тем подписок (topics) и их подписчиков. Когда очередь получает сообщение для какой-то темы, то помещает его в соответствующий список. Сообщение сопоставляется с темой по типу сообщения или по заранее определённому набору критериев, включая и содержимое сообщения.
  • На основе вещания
    Когда очередь получает сообщение, она транслирует его всем узлам, прослушивающим очередь. Узлы должны сами фильтровать данные и обрабатывать только интересующие сообщения.

Все эти паттерны можно отнести к либо к pull- (polling) , либо к push -подходу:

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

Достоинства

• Независимость набора технологий, развёртывания и масштабируемости сервисов.
• Стандартный, простой и надёжный канал связи (передача текста по HTTP через порт 80).
• Оптимизированный обмен сообщениями.
• Стабильная спецификация обмена сообщениями.

Недостатки

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

Сервисная шина предприятия (ESB)

Сервисная шина предприятия использовала веб-сервисы уже в 1990-х, когда они только развивались (быть может, некоторые реализации сначала использовали CORBA?).

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

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

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

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

Это очень упрощённое описание архитектуры ESB. Более того, хотя ESB является главным компонентом архитектуры, в системе могут использоваться и другие компоненты вроде доменных брокеров (Domain Broker), сервисов данных (Data Service), сервисов процессной оркестровки (Process Orchestration Service) и обработчиков правил (Rules Engine). Тот же паттерн может использовать интегрированная архитектура (federated design): система разделена на бизнес-домены со своими ESB, и все ESB соединены друг с другом. У такой схемы выше производительность и нет единой точки отказа: если какая-то ESB упадёт, то пострадает лишь её бизнес-домен.

Главные обязанности ESB:

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

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

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

Достоинства

• Независимость набора технологий, развёртывания и масштабируемости сервисов.
• Стандартный, простой и надёжный канал связи (передача текста по HTTP через порт 80).
• Оптимизированный обмен сообщениями.
• Стабильная спецификация обмена сообщениями.
• Изолированность контекстов домена (Domain contexts).
• Простота подключения и отключения сервисов.
• Асинхронность обмена сообщениями помогает управлять нагрузкой на систему.
• Единая точка для управления версионированием и преобразованием.

Недостатки

• Ниже скорость связи, особенно между уже совместимыми сервисами.
• Централизованная логика:
  • Единая точка отказа, способная обрушить системы связи всей компании.
  • Большая сложность конфигурирования и поддержки.
  • Со временем можно прийти к хранению в ESB бизнес-правил.
  • Шина так сложна, что для её управления вам потребуется целая команда.
  • Высокая зависимость сервисов от ESB.

Микросервисы

В основе микросервисной архитектуры лежат концепции SOA. Назначение у неё то же, что и у ESB: создать единое общее корпоративное приложение из нескольких специализированных приложений бизнес-доменов.

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

То есть в случае с ESB у нас уже были приложения, которые нам не «принадлежат» , и поэтому мы не могли их изменить. А в случае с микросервисами мы полностью контролируем приложения (при этом в системе могут использоваться и сторонние веб-сервисы).

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

[Микросервисы - это] маленькие автономные сервисы, работающие вместе и спроектированные вокруг бизнес-домена.
- Sam Newman 2015, Principles Of Microservices

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

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

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

Сообщество предпочитает другой подход: умные конечные точки и глупые каналы . Микросервисы, из которых собираются приложения, должны как можно меньше зависеть друг от друга и при этом быть очень тесно связанными - они содержат собственную доменную логику и работают скорее как фильтры с точки зрения классического Unix: получают запросы, применяют логику и генерируют ответы. Они оркестрируются с помощью простых REST-подобных протоколов, а не сложных протоколов вроде WS-Choreography или BPEL либо какого-то централизованного инструмента.
- Martin Fowler 2014, Microservices

Достоинства

• Независимость набора технологий, развёртывания и масштабируемости сервисов.
• Стандартный, простой и надёжный канал связи (передача текста по HTTP через порт 80).
• Оптимизированный обмен сообщениями.
• Стабильная спецификация обмена сообщениями.
• Изолированность контекстов домена (Domain contexts).
• Простота подключения и отключения сервисов.
• Асинхронность обмена сообщениями помогает управлять нагрузкой на систему.
• Синхронность обмена сообщениями помогает управлять производительностью системы.
• Полностью независимые и автономные сервисы.
• Бизнес-логика хранится только в сервисах.
• Позволяют компании превратиться в сложную адаптивную систему, состоящую из нескольких маленьких автономных частей/команд, способную быстро адаптироваться к переменам.

Недостатки

• Высокая сложность эксплуатации:
  • Нужно много вложить в сильную DevOps-культуру.
  • Использование многочисленных технологий и библиотек может выйти из-под контроля.
  • Нужно аккуратно управлять изменениями входных/выходных API, потому что эти интерфейсы будут использовать многие приложения.
  • Использование «согласованности в конечном счёте» (eventual consistency) может привести к серьёзным последствиям, которые нужно учитывать при разработке приложения, от бэкенда до UX.
  • Тестирование усложняется, потому что изменения в интерфейсе могут непредсказуемо влиять на другие сервисы.

Антипаттерн: архитектура равиоли (Ravioli Architecture)

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

Заключение

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

Эволюция шла по классическому пути: сложные проблемы разбивались на более мелкие, простые в решении.

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

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

Итак, для чего придумали SOA? Количество и сложность используемых в компаниях информационных систем растет, требования бизнеса к ним возрастают тоже, и модернизировать КИС становится все труднее и дороже. Возникает противоречие: частые изменения в бизнес-процессах требуют от ИТ-специалистов максимальной скорости их внесения, однако с точки зрения экономической эффективности стоимость владения КИС необходимо минимизировать. Головной боли добавляют задачи по интеграции процессов между несколькими компаниями.

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

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

Архитектура предприятия

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

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

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

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

Основные принципы SOA

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

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

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

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

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

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

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

Преимущества и сложности подхода SOA

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

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

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

Для унификации описания процессов все чаще используется Business Process Executive Languages (BPEL) - язык исполнения бизнес-процессов, и его место в SOA очень важно, поскольку такое описание является необходимым условием для внедрения SOA. При этом оно должно быть понятным как владельцам бизнес-процессов, так и информационным системам. В данном случае использование нотации eEPC (событийной цепочки управления бизнес-процессом) для уровня бизнеса с последующей трансформацией полученных моделей в BPEL позволяет минимизировать затраты на формализацию процессов и их автоматизацию. На основании языка BPEL система автоматизации будет вызывать требуемые описанные сервисы, чтобы передать им необходимую для выполнения информацию.

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

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

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

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

Пока еще не создано полноценных ИТ-инструментов, которые могут стать основой для реализации SOA. Это остается одним из основных препятствий к ее распространению. Существующие приложения не в состоянии поддержать SOA в полном объеме. Проблемы с надежностью и информационной безопасностью полученного «композитного» приложения тоже могут поставить крест на SOA. Ведь сейчас нужно контролировать деятельность нескольких информационных систем, а в случае внедрения SOA следить придется за множеством различных сервисов, взаимодействующих между собой, причём как через уровень автоматизации бизнес-процессов, так и напрямую. Итак, для перехода от стандартной ERP-системы к сервисно-ориентированному подходу нужно будет переработать большинство имеющихся на рынке программных продуктов и разработать огромное количество решений, что маловероятно в ближайшие год-два.

Заключение

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

Первые шаги к SOA

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

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

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

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

Сервис-ориентированная архитектура (SOA, service-oriented architecture) – модульный подход к разработке программного обеспечения, основанный на использовании сервисов (служб) со стандартизированными интерфейсами [21 ].

OASIS (Организация по распространению открытых стандартов структурированной информации) определяет SOA следующим образом (OASIS Reference Model for Service Oriented Architecture V 1.0): Сервисно-ориентированная архитектура – это парадигма организации и использования распределенных информационных ресурсов таких как: приложения и данные, находящихся в сфере ответственности разных владельцев, для достижения желаемых результатов потребителем, которым может быть: конечный пользователь или другое приложение.

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

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

Интерфейс компонентов SОА-программы предоставляет инкапсуляцию деталей реализации конкретного компонента (ОС, платформы, языка программирования, вендора, и т. п.) от остальных компонентов. Таким образом, SOA предоставляет гибкий и элегантный способ комбинирования и многократного использования компонентов для построения сложных распределенных программных комплексов.

SOA хорошо зарекомендовала себя для построения крупных корпоративных программных приложений. Целый ряд разработчиков и интеграторов предлагают инструменты и решения на основе SOA (например, платформы IBM WebSphere, Oracle/BEA Aqualogic, Microsoft Windows Communication Foundation, SAP NetWeaver, ИВК Юпитер, TIBCO, Diasoft).

Основными целями применения SOA для крупных информационных систем, уровня предприятия, и выше являются :

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

расширение повторного использования кода;

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

повышение масштабируемости создаваемых систем;

улучшение управляемости создаваемых систем.

Принципы SOA:

архитектура , как таковая, не привязана к какой-то определенной технологии;

независимость организации системы от используемой вычислительной платформы (платформ);

независимость организации системы от применяемых языков программирования;

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

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

Архитектура не привязана к какой-то определенной технологии. Она может быть реализована с использованием широкого спектра технологий, включая такие технологии как REST, RPC, DCOM, CORBA или веб-сервисы. SOA может быть реализована, используя один из этих протоколов и, например, может использовать, дополнительно, механизм файловой системы, для обмена данными.

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

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

Таким образом, системы, основанные на SOA, могут быть независимы от технологий разработки и платформ (таких как Java, .NET и т. д.). К примеру, сервисы, написанные на C#, работающие на платформах.Net и сервисы на Java, работающие на платформах Java EE, могут быть с одинаковым успехом вызваны общим составным приложением. Приложения, работающие на одних платформах, могут вызывать сервисы, работающие на других платформах, что облегчает повторное использование компонентов.

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

Языки высокого уровня, такие как BPEL, или спецификации, такие как WS-CDL и WS-Coordination, расширяют концепцию сервиса, предоставляя метод оркестрации, для объединения мелких сервисов в более обширные бизнес-сервисы, которые, в свою очередь, могут быть включены в состав технологических процессов и бизнес-процессов, реализованных в виде составных приложений или порталов.

Вячеслав Ерохин

В статье рассматривается сервис-ориентированная архитектура (SOA ) как бизнес-концепция. Предлагается подход к управлению жизненным циклом SOA с помощью методики «Управление SOA » (SOA Governance ), основанной на средствах управления архитектурой предприятия (Enterprise Architecture Management ) и стратегического управления ИТ.

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

SOA – это архитектура

SOA – Service Oriented Architecture – архитектура, ориентированная на сервисы. SOA – это прежде всего бизнес-концепция архитектурного подхода к построению предприятия. Более ранние концепции не ставили в центр внимания архитектуру предприятия

SOA – первая широко известная бизнес-концепция, концентрирующаяся на архитектуре. Таким, образом, SOA надо понимать и применять в контексте управления архитектурой предприятия (Enterprise Architecture Management ). Архитектура предприятия включает разные слои: бизнес-архитектура, информационная архитектура, техническая архитектура и т.д. SOA начинается с уровня бизнес-архитектуры.

SOA – это сервисы

Концепция SOA концентрируется на архитектуре, но архитектуре ориентированной на сервисы. Что такое сервисы и в чем разница с более ранними концепциями?

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

Таким образом, в SOA стоит выделить первый уровень - бизнес-архитектуры. В свою очередь бизнес-сервисы не существуют в отрыве от миссии компании, ее стратегии и целей. Бизнес-сервисы вытекают из места компании во внешней конкурентной среде. Долгосрочное развитие бизнеса может быть основано только на конкурентных преимуществах и их сочетании, обеспечивающем синергетический эффект. Обычно таких преимуществ немного – два-три. Большая удача – если их пять-шесть. Главная задача выживания компании – это задача создания и сохранения ее конкурентных преимуществ. Но конкурентные преимущества – или по-другому бизнес-потенциалы (Business Capabilities ) – не строятся на основе процессов. Это функции компании как целого организма во внешней среде.

Бизнес-потенциалы

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

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

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

Основные правила, заложенные в основу концепции бизнес-потенциалов:

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

• взаимодействие уровней управления для согласованной поддержки бизнес-потенциалов.

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

• обеспечить сохранение поддержки критически важных бизнес-потенциалов
• обеспечить достижение стратегических целей предприятия.

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

Сервис или процесс

Бизнес-потенциалы (Business Capabilities ) легко декомпозировать в бизнес-сервисы, но трудно – в бизнес-процессы. Сервисный подход ориентирован на стратегические цели компании – создание и сохранение бизнес-потенциалов.

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

В сервисном подходе –именно бизнес-сервис является основным объектом планирования и управления. Бизнес-процесс – это способ реализации бизнес-сервиса. В процессном подходе первичен бизнес-процесс, как уникальная цепочка создания стоимости. Бизнес-сервис в процессном подходе либо не актуализируется вовсе и заменяется на технический сервис, либо является подчиненным элементом бизнес-процесса, кирпичиком из которых строится бизнес-процесс.

SOA – это не технологическая платформа

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

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

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

SOA – вместо реинжиниринга бизнес-процессов – реинжиниринг предприятия

Стив Джонс, автор книги «Enterprise SOA Adoption Strategies. Using SOA to deliver IT to the businesss» утверждает: «Большинство компаний совершают одну принципиальную ошибку в отношении технологий: они рассмативают их через призму существующих процессов. Компании спрашивают: "Как эти новые технологические возможности могут улучшить и оптимизировать текущую работу?" Но вместо этого они должны спрашивать: "Что новое могут позволить нам делать технологии?" В отличие от автоматизации суть реинжиниринга - в новаторстве, в использовании новейших технологических возможностей для достижения совершенно новых целей. Один из самых сложных элементов реинжиниринга - умение найти новые, незнакомые возможности технологии».

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

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

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

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

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

SOA требует не реинжиниринга бизнес-процессов на предприятии, а конструирование бизнес-процессов из набора бизнес-сервисов. SOA предполагает наличие бизнес-процесса по конструированию бизнес-процессов. Такой бизнес-процесс называется SOA Governance .

Что такое SOA Governance ?

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

SOA Governance – это процесс управления жизненным циклом предприятия, построенного на основе SOA . SOA Governance – это также инфраструктура управления жизненным циклом SOA . Эффективное управление SOA - это не просто технология. Это подход к жизненному циклу, в котором участвуют все ответственные сотрудники организации, и учитываются различные активы организации.

Создание инфраструктуры управления SOA, предполагает решение ряда типовых задач:

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

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

Создание высокоэффективных бизнес-сервисов

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

Реализация подхода SOA Governance позволяет ответить на следующие вопросы:

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

Управление жизненным циклом сервисов

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

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

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

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

Оценка эффективности

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

Процесс SOA Governance

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

Процесс SOA Governance состоит из четырех этапов:

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

Планирование инфраструктуры SOA

На этапе планирования анализируются потребности организации и выявляются области, в которых требуется более эффективное управление.

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

На этом этапе реализуются следующие мероприятия:

• Выделение в ИТ-стратегии компании направления, ориентированного на использование SOA.
• Определение необходимого уровня возможностей ИТ и SOA
• Формулирование и уточнение видения и стратегии развития SOA
• Изучение возможностей и проводимые мероприятия в области управления SOA .
• Разработка плана управления SOA.

Согласование и определение - проработка подхода к управлению SOA

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

На этапе определения принимаются различные решения в области управления SOA :

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

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

На этапе реализации решения по управлению SOA претворяются в жизнь. На этом этапе выполняются следующие работы:

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

Функционирование и оценка - мониторинг внедренных решений и управление ими

На этапе оценки осуществляется мониторинг методов и механизмов управления, выявленных на этапе определения и внедренных на этапе реализации.

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

• Контроль выполнения разработанных политик и методов управления, таких как соглашения об уровне обслуживания, анализ уровня повторного использования и изменения политик
• Анализ показателей эффективности бизнес-архитектуры и ИТ-инфраструктуры.

Инструменты SOA Governance

Эффективное управление предприятия, построенного на основе SOA возможно только с использованием соответствующего инструментария.

Требования к инструментарию SOA Governance позволяют сформировать набор продуктов, отвечающий задачам управления SOA :

Поддержка архитектурного подхода

Инструмент SOA Governance должен обеспечивать поддержку текущей, целевой и планируемой архитектур предприятия. Архитектура предприятия должна содержать не только технический и информационный слои, но и бизнес-слой.

Поддержка элементов сервис-ориентированной архитектуры

Инструмент SOA Governance должен обеспечивать поддержку элементов сервис-ориентированной архитектуры. Наиболее важной является поддержка типов артефактов:

• Логический сервис (бизнес-сервис)
• Технический сервис (веб-сервис)
• Функциональный домен
• Функциональный модуль
• Техническая операция

Поддержка процесса управления жизненным циклом сервис-ориентированной архитектуры

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

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

Ведущие поставщики программного обеспечения предлагают различные наборы инструментов, реализующих SOA Governance . Наиболее функционально полные решения предлагают компании IBM , Oracle , Software AG .

Пример реализации SOA Governance на основе Oracle Fusion Middleware и системы управления архитектурой предприятия Alfabet planningIT

Интегрированное решение на основе alfabet planningIT и Oracle Fusion Middleware позволяет предоставить сквозную услугу по управлению жизненным циклом ИТ-инфраструктуры на основе SOA . Благодаря взаимодействию Oracle Fusion Middleware и alfabet planningIT можно успешно проектировать, разрабатывать и внедрять сервис-ориентированную архитектуру (SOA ).

Решение alfabet /Oracle обладает определенными преимуществами перед другими решениями SOA Governance :

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

Процессы, поддерживаемые интегрированным решением

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

Функции, поддерживаемые интегрированным решением.

• Создание в planningIT описания технических сервисов (WSDL ), соответствующих технической реализации логических сервисов, их экспорт в репозитарий Oracle .
• Генерация из planningIT проектов Java в Oracle IDE для реализации соответствующих технических сервисов.
• Импорт из Oracle в planningIT существующих технических сервисов для планирования бизнес-приложений и логических сервисов.
• Формирование в planningIT описания бизнес-приложений в терминологии SOA – как набора логических сервисов, реализованных в виде технических сервисов (веб-сервисов).
• Построение в planningIT упрощенных диаграмм процессов BPEL и их экспорт в Oracle .
• Импорт из Oracle BPEL Engine в planningIT статистики об использовании сервисов для целей централизованного планирования SOA .

Компоненты, используемые в интегрированном решении

Компоненты Oracle Fusion Middleware (FMW ):

• Oracle Services Registry (UDDI) – центральный реестр сервисов
• BPEL PM & BPEL Designer (JDeveloper) – разработка и выполнение процессов на BPEL
• Датчики (sensors) – сбор и нформации о KPI процесса
• Web Services Manager – управление доступом к веб-сервисам

Компоненты alfabet planningIT :

• Logical Inventory – единый репозитарий на основе развитой метамодели
• Application Architecture Management – управление архитектурой приложений
• Enterprise Architecture Management – управление архитектурой предприятия

Стадия планирование

Система управления архитектурой предприятия и стратегического планирования ИТ Alfabet planningIT поддерживает планирование «сверху-вниз» с возможностью многослойного обзора ИТ-активов: бизнес-требования, бизнес-процессы, организационная структура, поддержка бизнеса со стороны ИТ, бизнес-приложения, сервисы. Это позволяет оценить насколько эффективно ИТ-инфраструктура обеспечивает поддержку бизнес-стратегии, стратегических целей, бизнес-процессов и т.п. Кроме того, становится возможным рассчитать стоимость изменений в ИТ-инфрастуктуре.

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

Основным объектом интеграции alfabet planningIT и Oracle Fusion Middleware является объект «Сервис». В репозитарии alfabet planningIT существует артефакт «Технический сервис» (Technical Service ), который корреспондирует с термином «Сервис» (Service ) в SOA . Такой сервис может быть описан с использованием WSDL . Технический сервис в planningIT может быть создан или повторно использован для технической реализации логических сервисов. Логические сервисы в planningIT могут быть объединены в форме бизнес-приложений. Бизнес-приложение является артефактом репозитария, играющим ключевую роль в процессе планирования, управления, анализа затрат и т.п.

Продукты Oracle обеспечивают интегрированную поддержку проектирования, реализации и внедрения сервисов. Oracle Fusion Middleware реализует сервисную шину предприятия (ESB ) и оркестровку сервисов (BPEL ), а также предоставляет возможности мониторинга развернутых сервисов с помощью репозитария сервисов.

Система Alfabet planningIT также предоставляет инструментарий для оценки влияния изменений и проведения анализа затрат внедрения изменений. Oracle Fusion Middleware обеспечивает поддержку реализации, развертывания и выполнения сервисов, спланированных и прототипированных в planningIT .

Стадия согласование (определение)

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

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

Стадия разработка (реализация)

Для обеспечения технической реализации логических сервисов пользователи planningIT могут детализировать описание логических сервисов в терминах технических сервисов. При этом технические сервисы могут быть импортированы из репозитария веб-сервисов Oracle . Если же необходимого технического сервиса не существует, то описание такого сервиса может быть создано в planningIT и затем опубликовано в репозитарии Oracle (OraSR +WSM ) со статусом «В стадии разработки». В то же время генерируется новый проект Java для реализации соответствующего технического сервиса.

Диаграмма процессов BPEL в Oracle соотносится с объектом бизнес-приложение (Business Application ) в репозитарии planningIT . Бизнес-приложение в planningIT – это набор бизнес-сервисов, которые поддерживают бизнес деятельность – а не программный компонент. Таким образом, бизнес-приложение может быть описано в виде диаграммы BPEL , описывающей оркестровку технических сервисов.

Бизнес-приложение может быть экспортировано из planningIT в виде проекта BPEL в формате XML . Все технические сервисы, соответствующие бизнес-приложению, должны быть включены в проект в формате XML и экспортированы в репозитарий Oracle (OraSR +WSM ). Диаграмма BPEL , разработанная в planningIT также может быть экспортирована для последующего использования в среде разработки Oracle (Oracle IDE ).

Стадия функционирование (оценка)

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

Сквозная интеграция alfabet planningIT с Oracle FMW означает, что предприятия теперь могут вести управление эволюцией элементов SOA и жизненным циклом сервисов на основе надежных и последовательных данных и визуальной информации.

Модуль «Управление архитектурой предприятия» planningIT может использоваться для передачи и агрегирования данных с уровня внедренных сервисов на уровень бизнес-планирования, где менеджеры осуществляют оценку рисков, затрат, доступности и качества ИТ-сервисов для важных бизнес-процессов и продуктов. planningIT может импортировать статистику об использовании сервисов из Oracle BPEL Engine . Эта информация может использоваться для централизованного планирования SOA .

Заключение

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