Сервис-ориентированная архитектура (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

Часть 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) за рецензию на эту статью.

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

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

• Сервисы инфраструктуры. Данные сервисы выполняют проводящую функцию, посредством платформы, через которую поставляются сервисы бизнес-функций.

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

Мировой рынок SOA

Российский рынок SOA

Развитие SOA

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

Своего рода предшественницей SOA стала технология Enterprise Service Bus , предоставлявшая унифицированный механизм взаимодействия приложений. Дополненная рядом других технологий, ESB позволила сформировать единую интеграционную платформу. По-видимому, качественный переход к SOA начался в тот момент, когда появилась возможность создавать поверх этого интеграционного слоя новые прикладные решения с использованием уже существующего функционала.

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

Сервисно-ориентированное и объектно-ориентированное программирование

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

Как известно, повторное использование программного кода упрощает разработку больших информационных систем. До недавнего времени с этой целью традиционно применялся объектно-ориентированный подход, подразумевающий жёсткое объединение компонентов и объектов приложения в одно целое. В парадигме ООП от разработчика требуется знание прикладного программного интерфейса, в котором объединены атрибуты и методы, сообща реализующие необходимый функционал. Но поскольку объектные системы обычно создаются на основе какого-то одного языка программирования (Delphi , C Яык программирования++ , C Яык программирования# , Java и др.) и фиксированных механизмов обмена информацией между объектами и модулями информационной системы, то и в ООП сохраняются все зависимости и ограничения. Такой подход удобен не всегда - в частности, он не позволяет оперативно реагировать на изменение ситуации и, к примеру, проектировать новомодные системы, опирающиеся на концепцию «ресурсы по требованию». Кроме того, для модификации объектных систем нередко приходится переписывать коды связанных объектов и методов.

Cвести эти ограничения к минимуму позволяет технология SOA, которая многими уже признана как революция в технологии программирования.

Аналитики о сервисно-ориентированной архитектуре

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

Архитектурные особенности SOA

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

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

Архитектура веб-сервисов также является сервисно-ориентированной. Более того, веб-сервисы - это суть SOA c двумя дополнительными ограничениями: интерфейсы базируются на интернет-протоколах (HTTP , FTP , SMTP Simple Mail Transfer Protocol - Простой протокол передачи почты , TCP), а все сообщения описываются в формате XML . Детальные описания стандарта веб-сервисов и спецификаций SOA приводятся на сайтах консорциума W3C и организации OASIS .

Практические аспекты применения SOA

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

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

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

Вот шесть механизмов, с помощью которых поддерживается SOA-политика:

• Операционная модель жизненного цикла SOA
• Организация SOA
• SOA-процесс
• Портфель активов для сервисной интеграции в SOA
• Инструментарий SOA
• SOA-технологии

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

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

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

• Сервисы инфраструктуры. Данные сервисы выполняют проводящую функцию, посредством платформы, через которую поставляются сервисы бизнес-функций.

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

Мировой рынок SOA

Российский рынок SOA

Развитие SOA

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

Своего рода предшественницей SOA стала технология Enterprise Service Bus , предоставлявшая унифицированный механизм взаимодействия приложений. Дополненная рядом других технологий, ESB позволила сформировать единую интеграционную платформу. По-видимому, качественный переход к SOA начался в тот момент, когда появилась возможность создавать поверх этого интеграционного слоя новые прикладные решения с использованием уже существующего функционала.

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

Сервисно-ориентированное и объектно-ориентированное программирование

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

Как известно, повторное использование программного кода упрощает разработку больших информационных систем. До недавнего времени с этой целью традиционно применялся объектно-ориентированный подход, подразумевающий жёсткое объединение компонентов и объектов приложения в одно целое. В парадигме ООП от разработчика требуется знание прикладного программного интерфейса, в котором объединены атрибуты и методы, сообща реализующие необходимый функционал. Но поскольку объектные системы обычно создаются на основе какого-то одного языка программирования (Delphi , C Яык программирования++ , C Яык программирования# , Java и др.) и фиксированных механизмов обмена информацией между объектами и модулями информационной системы, то и в ООП сохраняются все зависимости и ограничения. Такой подход удобен не всегда - в частности, он не позволяет оперативно реагировать на изменение ситуации и, к примеру, проектировать новомодные системы, опирающиеся на концепцию «ресурсы по требованию». Кроме того, для модификации объектных систем нередко приходится переписывать коды связанных объектов и методов.

Cвести эти ограничения к минимуму позволяет технология SOA, которая многими уже признана как революция в технологии программирования.

Аналитики о сервисно-ориентированной архитектуре

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

Архитектурные особенности SOA

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

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

Архитектура веб-сервисов также является сервисно-ориентированной. Более того, веб-сервисы - это суть SOA c двумя дополнительными ограничениями: интерфейсы базируются на интернет-протоколах (HTTP , FTP , SMTP Simple Mail Transfer Protocol - Простой протокол передачи почты , TCP), а все сообщения описываются в формате XML . Детальные описания стандарта веб-сервисов и спецификаций SOA приводятся на сайтах консорциума W3C и организации OASIS .

Практические аспекты применения SOA

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

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

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

Вот шесть механизмов, с помощью которых поддерживается SOA-политика:

• Операционная модель жизненного цикла SOA
• Организация SOA
• SOA-процесс
• Портфель активов для сервисной интеграции в SOA
• Инструментарий SOA
• SOA-технологии

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

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

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

«Проблема в том, что в аббревиатуре SOA люди больше обращают внимание на «service oriented», нежели на «architecture». Однако именно архитектура и дисциплина могут помочь SOA принести реальный результат».

Джеймс Гавернор (James Governor), ведущий аналитик, компания Redmonk

Термин SOA пока что несет на себе сильный маркетинговый отпечаток, а для самого понятия SOA на сегодняшний день все еще существуют различные трактовки. Многие отождествляют SOA с технологией Web-сервисов или определенными информационными системами, например, системами для управления бизнес-процессами (Business Process Management, BPM). Но SOA — это не коробочный продукт или технология, а идеология информатизации бизнеса, основанная на процессном подходе и методологии управления бизнес-процессами BPM.

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

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

Принципы SOA

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

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

Аналогичная ситуация складывается сейчас с информационными решениями. Многие уже поняли на своем опыте, что монолитные системы (ERP, CRM, SCM и т. д.) обладают двумя врожденными пороками: ограниченной гибкостью (не всегда позволяют внести требуемые изменения в необходимые сроки) и высокой стоимостью владения и внесения изменений. Эти два фактора критичны для современных компаний, работающих в высококонкурентном и динамичном мире, что заставляет их уделять пристальное внимание оптимизации в данной области.

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

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

Оценив сложившуюся маркетинговую ситуацию и потенциал SOA для бизнеса, ведущие поставщики информационных систем поспешили заявить о своей готовности к SOA. Не отставали здесь ни пресса, ни аналитики. Если вспомнить начало кампании в 2005 г., то все единодушно говорили о большом потенциале SOA, и как следствие в 2006-2007 гг. было начато множество пилотных проектов SOA. Затем появилась информация о первых результатах, первых трудностях и неудачах. Темпы развития рынка SOA оказались не столь высоки, как ожидалось. По данным аналитиков, 90% компаний, запустивших пилотные проекты, завязли в них.

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

Цели и средства внедрения SOA

Изначально при внедрении SOA ставятся следующие цели:

• сокращение времени адаптации сложных информационных систем к постоянно изменяющимся бизнес-процессам компании;
• снижение стоимости владения ИТ (Total Cost of Ownership, TCO) в масштабе времени — за счет сокращения затрат на проектирование, внедрение, документирование, внесение изменений и т. п.;
• систематизация компонентов ИТ-архитектуры и повышение степени интегрированности информационных систем компании.

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

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

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

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

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

Условия успешного применения SOA

Несмотря на то что все ведущие вендоры ИТ-мира вписали в свои маркетинговые материалы аббревиатуру SOA, а заказчики все чаще требуют от внедренцев, чтобы ИТ-решение у них строилось с использованием принципов SOA, ясные и понятные цели SOA очень часто не достигаются. Причина в первую очередь кроется в низком уровне бизнес-культуры и процессной зрелости компаний. Поскольку SOA, как мы уже говорили, базируется на идеологии BPM, трудно поверить в «кусочное» внедрение SOA в какой-либо компании, разве что в узкотехнологическом аспекте — применении технологии Web-сервисов. Это подтверждается и опытом первых проектов SOA — многие из них, зайдя в тупик из-за непрозрачности ИТ-архитектуры и непонимания общей картины ИТ-поддержки бизнеса, вызвали к жизни проекты документирования и управления архитектурой предприятия (Enterprise Architecture, EA). И наоборот — успешные проекты описания архитектуры предприятия дали жизнь SOA-проектам, поскольку стало очевидно, в каких областях идеология SOA применима и может дать наибольший эффект.

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

Доходы будущих периодов

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

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

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

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

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

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

• расширение, а не сужение, «зоопарка» информационных систем и приложений,
• снижение надежности поддержки бизнеса;
• повышение стоимости владения ИТ;
• и в конечном счете — дискредитация идеологии SOA как таковой.

Заключение

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

Уроки первых проектов позволяют утверждать, что:

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

Не следует ждать немедленного сокращения времени внедрения и экономии от SOA: это «доходы будущих периодов», базирующиеся на предварительно созданной SOA-инфраструктуре и репозитории сервисов. Но если мы не хотим «остаться за бортом» и рассчитываем получить стратегические бизнес-преимущества, этим надо заниматься уже сейчас — потому что к 2010 г., согласно прогнозу аналитиков Gartner Group, по меньшей мере 65% больших компаний переведут более 35% своего портфеля приложений на SOA.

Андрей Коптелов , директор департамента развития и внедрения ИТ
Виктор Голубев , директор департамента продвижения продуктов и услуг компания «IDS Scheer Россия и страны СНГ»