Сервис-ориентированная архитектура и архитектура предприятия: Часть 1. Взаимодействие SOA и EA

Мамду Ибрахим, старший сертифицированный специалист в области архитектуры информационных систем, IBM
Гил Лонг, заслуженный инженер, IBM
http://www.ibm.com/developerworks/ru/library/ws-soa-enterprise1/

25.03.2008

В этой статье, первой из трех статей серии, мы представляем схему, которая облегчит вам понимание совместного использования принципов сервис-ориентированной архитектуры (Service-Oriented Architecture, SOA) и архитектуры предприятия (Enterprise Architecture, EA). Сначала вашему вниманию будет предложено краткое введение в SOA и EA и определение этих технологий. Затем мы покажем области применения и основные задачи SOA и EA, что поможет вам провести их эффективное сравнение и сопоставление.

Введение

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

• В части 1 даются определения и области применения SOA и EA, позволяющие создать инфраструктуру, в которой можно было бы выполнить корректное сравнение и сопоставление этих двух технологий;
• В части 2 осуществляется собственно сравнение и сопоставление SOA и EA. Здесь также рассказывается о потенциальных проблемах, которые могут возникнуть в тех случаях, когда предприятие уже разработало (или продолжает разрабатывать) EA, и только после этого начинает внедрять SOA;
• В части 3 приводятся рекомендации по решению этих проблем, разработанные на основе опыта, полученного при решении аналогичных проблем в проекте стоимостью 1.6 миллиардов долларов США, в рамках которого разработка SOA и EA велась параллельно.

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

• Область применения EA и область применения SOA (например, как можно использовать сходные аспекты двух технологий);
• Связь между Центром разработки и распространения передовых методов SOA (Center of Excellence, CoE) и советами управления EA (например, как избежать перекрытия областей применения);
• Ответственности и владение инфраструктурой SOA (например, в каком месте следует встроить шину Enterprise Service Bus (ESB) в инфраструктуру, и следует ли использовать ее исключительно для SOA?).

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

Определения EA

В исследовании Технологической академии IBM архитектура EA определяется следующим образом:

«Дисциплина EA определяет и обслуживает архитектурные модели, механизм управление и инициативы по переходу, необходимые для эффективной координации частично автономных групп для решения бизнес-задач- и/или ИТ-задач»

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

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

В литературе нет недостатка в описании инфраструктур EA. Захман первым сформулировал концепцию и опубликовал описание инфраструктуры для EA, которая была названа в его честь. После этого было опубликовано немало других инфраструктур EA, которые использовались многими организациями, особенно в области федерального управления. На рисунке 1 изображены примеры таких инфраструктур.
Рисунок 1. Различные модели EA, описанные в литературе.



Ниже представлена расшифровка сокращений, используемых на рисунке 1:

• FEAF — Federal Enterprise Architecture Framework (Инфраструктура архитектуры федеральной организации);
• TEAF — Treasury Enterprise Architecture Framework (Инфраструктура архитектуры казначейства);
• DoDAF — Department of Defense Architecture Framework (Инфраструктура архитектуры Министерства обороны);
• NASCIO — National Association of State Chief Information Officers (Национальная ассоциация государственных менеджеров по информационным технологиям).

На рисунке 2 изображена инфраструктура, разработанная в ходе исследования Технологической Академии IBM в области EA; она использует все концепции, упоминавшиеся в данном ранее определении и демонстрирует позиционирование EA как связующего звена между стратегией предприятия (в области бизнеса и информационных технологий), рабочей средой бизнеса и инфраструктурой ИТ. В следующих разделах мы продолжаем изучение различных аспектов EA.
Рисунок 2. Инфраструктура EA, разработанная IBM

EA - не только архитектура

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

Инфраструктура EA

Инфраструктура, созданная IBM, чтобы помочь организациям в разработке и реализации EA, состоит из нескольких предметных областей и механизма управления, показанных на рисунке 4.
Рисунок 4. Позиционирование предметных областей EA и управления в процессе планирования

Предметные области, которые необходимо смоделировать в составе EA, это:

• Бизнес-архитектура;
• Архитектура приложений;
• Архитектура информации;
• Архитектура технологии.

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

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

Определение CBDI:

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

Определение Gartner:

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

Определение IBM:
Поскольку IBM очень внимательно изучает взаимосвязь между SOA и бизнес-целями и бизнес- задачами предприятия, в Центре компетенции в области SOA в IBM разработали определение SOA, которое учитывает эти аспекты.

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

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

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

Определение с точки зрения архитектуры:

Архитектурный стиль, требующий наличия поставщика и запросчика сервисов, а также описаний сервисов.

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

Определение с точки зрения реализации:

Модель программирования, совместимая со стандартами, инструментами и технологиями Web-сервисов.

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

Стек SOA-решения

SOA состоит из процессов, сервисов и компонентов. Ядром SOA является модель сервиса, которая определяет сервисы и компоненты, с помощью которых они реализуются. На рисунке 6 показан стек SOA-решения и взаимосвязи между элементами, из которых состоит SOA.
Рисунок 6. Стек SOA-решения

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

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