EA SOA

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

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

Характерные черты сервисной ориентации бизнеса:

• Ориентация на бизнес, а не на возможности ИТ.

• Сервисы описываются в терминах интерфейсов, операций, семанти­

ки, динамических характеристик, политик и свойств.

• Повторное использование сервисов.

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

• Сервисы размещаются и становятся видимыми благодаря сервисным метаданным, реестрам и хранилищам.

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

Роли участников SOA:

1) Service consumer (потребитель сервисов) - приложение, про­граммный модуль или другой сервис, который требует обслу­живания. Он может инициировать запрос в реестре, вызывает транспорт и выполняет сервисную функцию в соответствии с контрактом.

2) Service provider (Поставщик услуг) - сетевая сущность, спо­собная принимать и выполнять запросы потребителей, публи­ковать сервисы и контракты в реестре услуг.

3) Service registry (Реестр/каталог сервисов) хранилище сервисов.

Механизмы взаимодействия ролей - рис.

Рисунок 28

Базовые операции в SOA:

1) Publish (Опубликовать) - сделать доступным описание сервиса.

2) Find (Найти) - обнаружение сервиса с помощью запросов в реестр сервисов по заданным критериям поиска.

3) Bind and invoke (Связь и вызов) - после получения описания сервиса и его нахождения.

Артефакты SOA: Service (Сервис)? Service description (Описание сервиса) - определяет способ обслуживания потребителей, взаимодей­ствия с поставщиком, форматы запроса и ответа.

Манифест SOA

Для реализации целей и задач SOA требуется формулировка и реа­лизация принципов, к которым относятся:

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

2. Обеспечение свободной связи сервисов (loose coupling), что означа­ет минимум зависимостей серверов друг от друга.

3. Описание бизнес-логики сервисов в абстрактном виде (abstraction) в контракте.

4. Повторное использование (reusability) сервисов.

5. Автономность (autonomy) - контроля над скрытой логикой сервисав течение жизненного цикла.

6. Отсутствие «гражданства» сервисов (statelessness), что означает свободу сервисов от государственной принадлежности.

7. Использование мета-описания сервисов для их обнаружения (discoverability) в каталогах/репозиториях сервисов.

8. Структурная композиция сервисов (composability), позволяющая создавать новые сервисы.

9. Детализация (granularity) сервисов с целью оптимизации размера и бизнес-функциональности для их применения.

10. Нормализация (normalization) сервисов для минимизации избыточ­ности.

11. Оптимизация (optimization) качества сервисов.

12. Соответствие (relevance) сервисов необходимой бизнес-

функциональности.

13. Инкапсуляция (encapsulation) сервисов внутри SOA.

14. Прозрачность места нахождения (transparency) сервисов.

Манифест SOA^[14]имеет следующее содержание.

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

Выделены приоритеты и их соответствие - приоритет 1-го уровня «выше» приоритета 2-го уровня (табл. 12).

Таблица 12

В Манифесте также сказано «Мы ценим значение вышеперечислен­ных понятий справа, однако ещё более ценим понятия слева».

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

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

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

Рисунок 29

В связи с развитием инструментария SOA появилась новая концеп­ция SOA 2.0, сервисно-ориентированной архитектуры в проекции на со­временные веб-сервисы.

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

Концепция жизненного цикла IBM SOA Foundation предусматривает следующие фазы SOA^[15]:

1. Моделирование (Model) - собираются требования к SOA. Бизнес- процессы предприятия моделируются, анализируются, проектиру­ются и оптимизируются для формирования будущих стандартных бизнес-процессов предприятия.

2. Сборка (Assemble) - сборка внедренных сервисов, компоновка и аранжировка для реализации корпоративных бизнес-процессов, про­верка соответствия как функциональным, так и иным требованиям к сервисам.

3. Развертывание (Deploy) в действующей среде исполнения.

4. Управление (Manage) - мониторинг и анализ сервисов и бизнес- процессов, выполняемых во время исполнения, обеспечение беспе­ребойной работы, измерение показателей безопасности, производи­тельности сервисов, совместимости с бизнес-метриками и соглаше­ниями об уровне сервиса (SLA), которым они должны соответство­вать.

5. Руководство (Governance) - всеми фазами управляет единый ком­плекс принципов руководства и передовых методик, создающий среду для тщательного надзора за действиями в каждой из фаз.

На рис. 30 указаны программные продукты компании IBM поддерж­ки жизненного цикла SOA.

Рисунок 30

Сбор и хранение требований к сервисам ориентировано на использо­вание Rational RequisitePro,моделирование бизнес-процессов - на WebSphere Business Modeler.Результаты моделирования бизнес- процессами служат входными данными для:

• Rational Software Architect,в котором выполняется построение SOA, проектирование и спецификация сервисов;

• WebSphere Business Monitorиспользуется для определения биз- нес-метрик (Key Perforance Indicators), которые необходимо измерять и контролировать во время выполнения бизнес- процессов;

• WebSphere Integration Developerобеспечивает представление бизнес-процесса в формате BPEL (Business Process Execution Language) - языке на основе XML для формального описания бизнес-процессов и протоколов их взаимодействия между со­бой, расширения модели взаимодействия веб-служб и включе­ния в эту модель поддержку транзакций.

Сервисы реализуются в Rational Application Developer,размещение сервисов и блоков компонентов J2EE выполняется на сервере WebSphere Application Server.Компоновка сервисов для реализации бизнес-процессов выполняется в WebSphere Integration Developer, со­бранные сервисы размещаются на сервере ППП WebSphere Process Serv­er,который использует WebSphere ESBдля медиации и маршрутизации сервиса.

Управление и контроль сервисов осуществляется с помощью плат­формы ITCAM (Tivoli Composite Application Manager - Управление служ­бами, приложений, промежуточным программным обеспечением, вирту­альными серверами и операционными системами). Управление безопасно­стью сервисов осуществляется с помощью Tivoli Federated Identity Manager, который создает федеративный единый вход и идентификаторы службы медиации. Распределенные комплексные транзакции отслежива­ют на всем пути через стек ИТ-продуктов с помощью ITCAM для Re­sponse Time Tracking.

Моделирование SOA состоит из трех этапов (рис. 31):

1. Идентификация сервиса. Определение функционала домена (предметной области) и его декомпозиция:

• Анализ существующих систем

• Моделирование «Цель - Сервис»

• Классификация сервисов (категоризация)

• Анализ подсистемы

2. Спецификация компонентов. Подсистемный анализ. Формирова­ние спецификаций потока компонентов и информации (данных). Специ­фикация сервисов на уровне потока, событий и сообщений. ИТ-решения в части местоположения компонентов сервисов и связи компонентов и сер­висов

3. Реализация сервисов

Рисунок 31

Эталонная архитектура SOA

Эталонная архитектура SOA состоит из слоев - рис. 32.

Рисунок 32

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

бизнес-процессов (Business Processes) выполняется композиция, хорео­графия бизнес-логики - выполняется создание композитных сервисов. Для поддержки SOA используется реестр/каталог сервисов (Services) предпри­ятия. Компоненты сервисов Service Components используются для постро­ения Services - служб, реализующих функциональные и технические ха­рактеристики ИТ. Реализация SOA на ИТ-платформе связана с уровнем Operational, на котором используются модели данных корпоративные хра­нилища данных, программный код и технологическая платформа.

Четыре вертикальных слоя применяются и поддерживаются каждым из горизонтальных слоев:

1. Стратегическое управление (Governance) для каждого горизонталь­ного слоя с целью удовлетворения эксплуатационных и функцио­нальных требований.

2. Информационная архитектура (Information) - предоставление мета­данных SOA, средств бизнес-аналитики для поддержки сервисов.

3. Инфраструктурные сервисы (Quality of Services), отвечающие за обеспечение безопасности, доступности, производительности и т. д. сервисов с учетом требований SLA (Service Level Agreement), ОLA (Operation Level Agreement).

4. Интеграция (Integration) - платформа поддержки протоколов, дан­ных, приложений, ведущих к интеграции корпоративных приложе­ний,поддерживающих «Business to business» - В2В и «Business-to- consumer»-В2С. Данный уровень соответствует Enterprise Service Bus (ESB) - программному обеспечению срединного типа, корпора­тивной сервисной шине для интеграции различных приложений и платформ.

Типичный поток взаимодействия между слоями эталонной в архи­тектуре SOA:

1. Потребители используют интерфейсный слой Consumer Interface, с помощью которого вводятся запросы, передаваемые интеграцион­ному слою - Integration.

2. Слой Integration вызывает бизнес-процессы, расположенные в слое Business Process, используя один или более сервисов слоя Services.

3. Слой Services связывается с компонентами сервиса, расположенны­ми в слое Service Components.

4. В свою очередь, службы компонентов слоя Services Components мо­гут настраиваться под запрос, они вызывают компоненты решения слоя Operational Systems на обслуживание.

5. Обработка информации осуществляется под управлением сервисов слоев Governance, Information, Quality of Service.

Operational Systems - среда выполнения и развертывания сервисов в рамках ИТ-инфраструктуры:

Уровень операционной системы = [Инфраструктурные элементы всех других слоев] + [Базовая инфраструктура для запуска инфра­структурных элементов (например, операционных систем и др.)] + [Элементы, реализующие Функциональные компоненты услуг]

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

Слой Service Components содержит программные компоненты в со­ответствии с концепциями Service Component Architecture (SCA) и Service Data Objects (SDO). Каждый компонент обеспечивает соблюдения согла­шений об уровне обслуживания (SLA), функциональную реализацию сер­виса, скрывая детали реализации от потребителей, выступает в роли фаса­да реализации сервисов и поддерживает ИТ гибкость через инкапсуляцию.

На рис. 33 дан пример композиции сервисов.

Приложение B (потребитель) имеет отношение к описанию открыто­го сервиса А, который использует сервисный компонент А в качестве фа­сада реализации этого сервиса. Компонент А объединяет программные пакеты X и Y. Изменение программного пакета, например, X на пакет M выполняется поставщиком и это касается только компонента А и не тре­бует изменения сервиса А.

Рисунок 33

В эталонной модели SOA определены типовые функциональные классы сервисов:

1. Интеграции унаследованных приложений и функций в SOA- решения - Access Services.

2. Бизнес-логики - Business Application Services.

3. Бизнес-задач - Business Services and Events.

4. Инструменты разработки сервисов SOA (визуальные, монтаж­ные, методики) - Development Services.

5. Информационные сервисы, поддерживающие доступ к данным бизнеса, информационным службам, организующие поток по­токи информации - Information Services.

6. Сервисы инфраструктуры для SOA-приложений - Infrastructure Services.

7. Компонентные сервисы для взаимодействия приложения и пользователя, презентации бизнес-логики, интерфейсов - Interaction Services.

8. Сервисы управления жизненным циклом сервисов (управление требованиями, конфигурацией сервисов) - Lifecycle Services.

9. Сервисы управления потоком, использованием ресурсов, вос­становлением сбоев и т.п. - Management Services.

10. Сервисы подключения для внешних пользователей - Partner Services.

11. Сервисы бизнес-дизайна сервисов - Process Services.

12. Сервисы стратегического планирования, корпоративной ар­хитектуры - Strategy and Planning Services.

Описание сервисов (Service Definition), политика предоставления сервиса (Policy Management), правила выполнения (Service Runtime Ena­blement) и контроль доступа (Access Control) используются в процессе ре­ализации сервисов службой кластеров (Service Clustering).

Эталонная модель SOA возникла на основе двух независимо разви- -16

вавшихся, но связанных по смыслу направлений : программирования; ин­тероперабельности программ и интеграции приложений.

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

¹⁶ http://www.ibm.com/developerworks/ru/edu/ws-soa-z_os/ch2/

Приложения используют программный код, создание которого прошло путь развития от структурного проектирования/программирования (SADT) в виде библиотек процедур, функций, макросов, программных модулей до объектно-ориентированного проектирования/программирования (OOAP), далее применялась модель компонентной структуры - COM/DCOM, а затем перешли к сервисам SOA и их тесной интеграции в контексте бизнеса.

Интерабельность приложений развивалась в направлении от прямого соединения приложений по типу «точка-точка» через использование бро­керов объектных запросов и построение магистрали сообщений до приме­нения ESB и стандартных интефейсов для сервисов SOA как способа ор­ганизации межпрограммного взаимодействия и многократного использо­вания сервисов на всех уровнях, вплоть до уровня бизнес-сервисов, под­держки автоматизированных и неавтоматизированных сервисов

Рисунок 34

Управление SOA

Единой модели эффективного управления SOA не существует, об­щими концептами моделей управления являются:

1. Стратегии SOA.

2. Оргструктура, процессы и инструменты управления SOA.

3. Портфель сервисов SOA.

4. Жизненный цикл сервисов SOA.

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

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

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

2. SOA Portfolio Governance - управление каталогом/репозиторием сервисов SOA, мх категоризация, анализ, идентификация, опреде­ление источников и поддержка взаимодействия сервисов.

3. Service Lifecycle Governance - управление жизненным циклом сер­висов.

4. SOA Solution Lifecycle Governance - управление жизненным цик­лом SOA-решений.

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

6. Active Leadership, Alignment and Strategic Planning - Активный лидер, выравнивание стратегий, стратегическое планирование, управление портфелем сервисов, управление жизненным циклом SOA.

7. Processes, Tools and Governance Infrastructure - Процессы, Инстру­менты и инфраструктура управления.

Управление SOA следует рассматривать как процесс, состоящий из последовательно выполняемых этапов: планирование, определение, раз­вертывание, мониторинг.