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

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

Мамду Ибрахим, старший сертифицированный специалист в области архитектуры информационных систем, IBM

Доктор Мамду Ибрахим (Mamdouh Ibrahim) является старшим сертифицированным специалистом в области архитектуры информационных систем и старшим техническим специалистом (STSM) в Центре изучения и распространения передовых методов архитектуры предприятия и технологий (Enterprise Architecture and Technology Center of Excellence). Кроме того, он является членом коллектива центра изучения и распространения передовых методов Web-сервисов SOA (SOA Web Services Center of Excellence). Доктор Ибрахим имеет более чем 30-летний производственный и академический опыт в сфере таких технологий, как EA (архитектура предприятия), SOA, распределенные вычислительные сети и беспроводные технологии. Он также работает в комитете по сертификации в области архитектуры информационных систем (IBM IT Architect Certification Board), является автором и инструктором курсов по развитию архитектурного мышления IBM (Architectural Thinking). Доктор Ибрахим имеет ученую степень доктора в области вычислительной техники; магистра в области вычислительной техники и математики и бакалавра в области электротехники и математики. Он является внештатным преподавателем в Центральном Мичиганском университете (Central Michigan University). Он был генеральным председателем на конференции OOPSLA 2002, а в настоящее время является председателем оргкомитета OOPSLA (до 2008 г). Доктор Мамду Ибрахим участвует в деятельности таких организаций, как ACM, Компьютерное сообщество IEEE и AAAI.



Гил Лонг, заслуженный инженер, IBM

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



25.03.2008

Введение

Внимательное изучение 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)

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

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

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

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

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

Рисунок 1. Различные модели EA, описанные в литературе.
Sample EA frameworks
Sample EA frameworks

Ниже представлена расшифровка сокращений, используемых на рисунке 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
IBM EA framework

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

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

Рисунок 3. EA состоит из архитектуры, механизма управления и плана-графика
IBM EA framework

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

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

Рисунок 4. Позиционирование предметных областей EA и управления в процессе планирования
Positioning EA domains and governance

Предметные области, которые необходимо смоделировать в составе 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 is more than architecture

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

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

Рисунок 6. Стек SOA-решения
SOA solution stack

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

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

Заключение

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

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

Особая благодарность Йану Чартерсу (Ian Charters), руководителю исследования Технологической Академии IBM по EA за предоставленные им данные, на основе которых были разработаны многие из схем, представленных в данной статье. Кроме того, мы хотим поблагодарить следующих сотрудников за их работу в этой области и ценные комментарии к черновым версиям этой презентации: Пол Бейт (Paul Bate), Люба Чербаков (Luba Cherbakov), Клаудио Коззи (Claudio Cozzi), Петер Де Мео (Peter De Meo), Рей Харишанкар (Ray Harishankar), Керри Холли (Kerrie Holley), Дон Хатчсон (Don Hutcheson), Дэвид Дженсон (David Janson), Стивен Барнс (Steven Barnes), Сатиш Кальяни (Satish Kalyani) и Шарон Форчун (Sharon Fortune).

Ресурсы

Научиться

Получить продукты и технологии

Обсудить

Комментарии

developerWorks: Войти

Обязательные поля отмечены звездочкой (*).


Нужен IBM ID?
Забыли Ваш IBM ID?


Забыли Ваш пароль?
Изменить пароль

Нажимая Отправить, Вы принимаете Условия использования developerWorks.

 


Профиль создается, когда вы первый раз заходите в developerWorks. Информация в вашем профиле (имя, страна / регион, название компании) отображается для всех пользователей и будет сопровождать любой опубликованный вами контент пока вы специально не укажите скрыть название вашей компании. Вы можете обновить ваш IBM аккаунт в любое время.

Вся введенная информация защищена.

Выберите имя, которое будет отображаться на экране



При первом входе в developerWorks для Вас будет создан профиль и Вам нужно будет выбрать Отображаемое имя. Оно будет выводиться рядом с контентом, опубликованным Вами в developerWorks.

Отображаемое имя должно иметь длину от 3 символов до 31 символа. Ваше Имя в системе должно быть уникальным. В качестве имени по соображениям приватности нельзя использовать контактный e-mail.

Обязательные поля отмечены звездочкой (*).

(Отображаемое имя должно иметь длину от 3 символов до 31 символа.)

Нажимая Отправить, Вы принимаете Условия использования developerWorks.

 


Вся введенная информация защищена.


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=40
Zone=SOA и web-сервисы
ArticleID=297198
ArticleTitle=Сервис-ориентированная архитектура и архитектура предприятия: Часть 1. Взаимодействие SOA и EA
publish-date=03252008