• Перевод

Сервис-ориентированная архитектура (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.
  • Тестирование усложняется, потому что изменения в интерфейсе могут непредсказуемо влиять на другие сервисы.

С помощью 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 Россия и страны СНГ»

Дословно SOA расшифровывается как service-oriented architecture (сервис-ориентированная архитектура).

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

Все крупнешие компание-производители программного обеспечиния (такие как IBM, BEA, Oracle) постоянно преподносят новости, которые так или иначе обыгрывают SOA. Большинство фирм-консалтеров и интеграторов различными способами информируют, что занимаются реализацией и внедрением сервис-ориентированной архитектуры у клиентов. Часто правда каждый понимает сервис-ориентированную архитекту́немного (или сильно) по своему.

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

Традиционные проблемы информационных систем

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

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

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

Определение SOA

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

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

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

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

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

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

Рассмотрим их немного подробнее.

Сервисы как компоненты информационной системы

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

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

Выбор распределенной технологии играет существенную роль. Использование, например, SNA или DCOM в качестве средства общения сервисов накладывают такое ограничение, при котором все компоненты в системе обязаны использовать SNA или DCOM, что ограничивает применимость системы.

Когда же говорят том, что информационная система следует принципам СОА, то сервис, реализованный, например, на языке Java и работающий в EE контейнере должен быть применим для использования клиентами, реализованными в Windows среде и наоборот.

Сервис выполняет повторяющуюся бизнес функцию

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

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

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

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

Это и является одним из главных достоинств SOA.

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

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

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

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

Низкая связанность (loose coupling)

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

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

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

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

Пример построенной на SOA информационной системы

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

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

Итак, основными компонентами (представлены на рисунке 1) являются сервисная шина предприятия (ESB), СОА реестр (SOA Registry), workflow engine, сервисный брокер (service broker), СОА супервизор (SOA supervisor) Все они играют собственную роль в системе, при этом взаимодействуя друг с другом.

Рисунок 1.

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

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

Для передачи сообщений в SOA как правило используют сервисную шину предприятия (Enterprise Service Bus – ESB). Сервисная шина является настолько важной в СОА, что возможно представить, что сервис-ориентированная архитектура не может существовать без нее и, наоборот, наличие ее является достаточным условием для SOA. На самом деле можно построить основанную на сервис-ориентированной архитектуре систему без применения сервисной шины и ее наличие не гарантирует позиционирование системы как СОА.

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

СОА реестр (SOA Registry):

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

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

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

СОА реестр также хранит информацию каждого компонента.

Workflow engine:

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

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

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

Продукты, моделирующие бизнес процессы, существовали задолго до СОА, существует огромное количество предложений от различных поставщиков, часто специализирующихся в различных областях. Около 15 лет назад большинство из этим систем были связаны с системами документооборота. Сейчас же поставщики этих систем все более тяготеют к системам управления бизнес-процессами и административными регламентами (business process management system или просто BPM).

Cервисный брокер (service broker):

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

Рисунок 2.

На рисунке 2 представлено как в некоторой СОА системе сервисный брокер организовывает обработку заказов. Схема включает только 4 бизнес сервиса и workflow engine.

Стрелками изображены действия сервисного брокера, утолщенные линии изображают потоки запросов.

Последовательность действий может выглядеть следующим образом:

1. Пользователь входит в систему и запрашивает службу обработки заказов. Поскольку эта служба еще не запущена, сервисный брокер получает соответствующее уведомление и начинает свою работу
2. Сервисный брокер запрашивает у СОА реестра, что необходимо для запуска службы обработки заказов и возможно ли ее стартовать в настоящее время
3. Сервисный брокер проверяет, запущены ли 4 необходимых для службы обработки заказов бизнес-сервиса, если еще не запущены, то стартует их.
4. На основании полученной от реестра СОА сервисный брокер проверяет интерфейсы между бизнес компонентами. Эти компоненты можно затем соединить вместе для службы обработки заказов.
5. Сервисный брокер уведомляет бизнес компоненты, что они должны связаться с workflow engine для выполнения необходимой службы и бизнесс процесс начинает выполняться

Некоторые реализации сервисной шины предприятия (ESB) выполняют также функции сервисного брокера.

СОА супервизор (SOA supervisor):

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

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

Трудно переоценить важность этого компонента.

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

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

Отправить свою хорошую работу в базу знаний просто. Используйте форму, расположенную ниже

Студенты, аспиранты, молодые ученые, использующие базу знаний в своей учебе и работе, будут вам очень благодарны.

Размещено на http://www.allbest.ru/

Размещено на http://www.allbest.ru/

Санкт-Петербургский государственный электротехнический университет

Кафедра МОЭВМ

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

Выполнил:

Орешко Д.В.

Санкт-Петербург 2004

программный инфраструктура операционный

Введение

1. Предпосылки

2. Архитектура SOA

3. Базовые стандарты SOA

4. Реестр сервисов

5. Оркестровка

6. Что такое Web-сервисы

8. Проблемы SOA

9. Достоинства

Литература

Введение

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

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

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

1. Предпосылки

Как решается задача интеграции приложений? Традиционный подход -- построение промежуточного программного слоя того или иного типа. Оптимальной для объединения разнородных платформ и решений выглядела технология взаимодействия распределенных объектов CORBA, позволявшая инкапсулировать бизнес-логику приложений, выполняющихся на разных платформах и созданных с использованием разных языков программирования, организовав связь между ними на базе строго описанных интерфейсов. Аналогичные возможности -- правда, с естественным ограничением гетерогенности -- предлагала корпорация Microsoft в рамках своей компонентной модели DCOM. Однако этим решениям не хватало универсальности; даже применение CORBA сильно зависело от реализации в продуктах разных поставщиков, появлялись новые объектные модели, не поддерживающие CORBA, интеграция по-прежнему реализовывалась на достаточно низком уровне, практически, исключая возможность динамичного изменения связей между приложениями в ходе выполнения. Важно и то, что все предлагаемые средства интеграции фокусировались на технологических особенностях реализации приложений и не позволяли учитывать специфику бизнес-процессов, в которых эти приложения использовались.

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

Еще одна серьезная проблема -- избыточность программных компонентов и сложность их многократного использования. В рис. 1 приводится пример программной инфраструктуры банка, включающей в себя несколько групп приложений для различных направлений банковской деятельности, которые были разработаны в рамках никак не связанных между собой проектов. В результате, с большей долей вероятности возможна ситуация, когда одна функция (скажем, получение баланса по вкладу) реализована многократно в системе автоматизации банкоматов, в системе поддержки филиалов и в системе расчетов по кредитным картам, -- даже если все эти системы используют одни и те же данные о счете из общей базы данных. А теперь предположим, что банк намерен разработать новые системы, например, для обслуживания клиентов в Internet или выдачи ссуд в режиме on-line. Расширение функциональности программной среды банка повлечет за собой дополнительную избыточность, если в этой среде отсутствуют механизмы многократного использования компонентов, поддерживающих различные задачи бизнеса. Все эти интеграционные проблемы и привели к появлению идеи сервисно-ориентированной архитектуры (service-oriented architecture, SOA). Для разрешения этих проблем простого набора технологий уже недостаточно. Нужен общий, архитектурный подход, концепция архитектуры программной среды предприятия, в которой возможна адекватная потребностям бизнеса динамика разработки, интеграции и эксплуатации приложений.

2. Архитектура SOA

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

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

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

Отметим некоторые из этих принципов.

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

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

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

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

Как бы неожиданно это ни показалось, перечисленные принципы были сформулированы американским архитектором Кристофером Александером в отношении архитектуры современного мегаполиса. В 1987 году он и его коллеги опубликовали работу под названием «Новая теория городского проектирования» (A New Theory of Urban Design), где излагались взгляды на возможность децентрализованного развития городов. В своей работе Александр показал, как можно осуществлять развитие городов с учетом существенной демографической разнородности жителей. Аналогичным образом SOA, основанная на адаптации этих принципов, позволяет объединить в общий взаимодействующий организм информационные системы, принадлежащие различным автономным организациям и их относительно автономным структурным подразделениям.

Общая схема.

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

Рис. 2. Общая схема SOA

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

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

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

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

Подобные контракты существовали и до появления Web-сервисов. Например, в архитектуре CORBA для описания интерфейса объектов использовался язык IDL, который уступает WSDL по ряду существенных параметров. Главный из них -- отсутствие поддержки XML и XML Schema, ставших наиболее распространенными языками разметки передаваемых по сети сообщений и представления моделей данных. Технические контракты, формулируемые провайдером сервисов, должны быть доступны потенциальным потребителям для интерпретации, анализа и реализации интеграции. Для этого используется специальный реестр, каталогизирующий доступные сервисы.

3. Базовые стандарты SOA

Набор базовых стандартов SOA держится на трех «китах». В их число, кроме WSDL и UDDI, входит протокол SOAP -- простой механизм для создания структурированных пакетов данных, предназначенных для обмена информацией между сервисами (сетевыми приложениями). Эту тройку стандартов объединяет то, что все они построены на базе языка XML и являются открытыми, то есть их развитием занимаются независимые комитеты по стандартизации. Чтобы понять, как они работают вместе, сравним технологию Web-сервисов с общением по телефону. В таком случае XML -- это язык, на котором ведется разговор, SOAP описывает правила набора номера, UDDI представляет собой телефонную книгу, а WSDL объясняет, что такое разговор по телефону и как его вести.

4. Реестр сервисов

Сейчас в области Web-сервисов сложились две группировки: одна включает IBM, BEA и Microsoft, а вторая -- Sun, Fujitsu и Oracle. Каждая из них продвигает свои разработки. Например, для управления транзакциями первая предлагает протокол WS-Transactions, а вторая -- WS-Transactions Management; для гарантированной доставки сообщений первая выпустила WS-ReliableMessaging, а вторая -- WS-Reliability. И так -- по всем направлениям технологии Web-сервисов. В результате на роль «заполнителей дыр» в SOA сейчас претендует множество различных методов, но явного лидера нет.

Была создана организация Web Services-Interoperability (http://www.ws-i.org/), которая пытается выработать некий общий знаменатель для технологии Web-сервисов. В августе нынешнего года она выпустила документ WS-I Basic Profile 1.1, определяющий требования к различным компонентам SOA, которые могут гарантировать их совместимость и прояснить тонкости использования Web-сервисов. Программный интерфейс реестра сервисов составляет часть стека протоколов взаимодействия. В наборе технологий Web-сервисов таким стандартом является UDDI (Universal Description, Discovery and Integration). Его спецификация является единственной из ядра основополагающих стандартов Web-сервисов, разработанной вне рамок консорциума World Wide Web Consortium. Таким ядром принято считать спецификации, входящие в профиль WS-I Basic Profile, призванный обеспечить общую для различных инструментальных платформ базу взаимно совместимых технологий описания, публикации, обнаружения и вызова сервисов.

Для разработки данной спецификации в 2000 году был сформирован Консорциум UDDI (UDDI.org), объединивший более 200 корпоративных членов. В соответствии со своим трехлетним мандатом, консорциум выпустил три версии спецификации и перестал существовать в 2003 году. Уже зрелый стандарт, реализованный многими разработчиками, UDDI был передан в организацию Organization for the Advancement of Structured Information Standards (OASIS), занимающую важное место в мире ИТ-стандартов. Текущей версией UDDI, официально принятой в качестве стандарта OASIS, является вторая; ратификация третьей версии ожидается в конце лета этого года, а технический комитет UDDI в составе OASIS уже разрабатывает очередную порцию нововведений.

UDDI обладает весьма развитой функциональностью, существенно более богатой чем, аналогичный компонент набора стандартов CORBA -- CORBA Naming Service. В отличие от предыдущих поколений реестров, UDDI был изначально нацелен на применение как внутри организаций, так и между ними, поэтому реестры UDDI одинаково удобны для ведения информации о нескольких или о тысячах сервисах. Для этого UDDI предусматривает гибкую информационную модель и средства распределения доступа. C точки зрения применимости UDDI в SOA, наиболее методологически значимым элементом информационной модели UDDI является возможность стандартизации типов сервисов (рис. 3). Интерфейс сервиса, описанный WSDL-документом, или даже отдельную его характеристику (скажем, стоимость или поддержка некоего протокола, такого, как HTTP Basic или WS-Security для авторизации) можно представить самостоятельным объектом метаданных в UDDI. Совокупность ссылок на такие объекты характеризует профиль интероперабельности данного сервиса. Используя те или иные параметры, потребитель может найти в реестре сервис, соответствующий его техническим или деловым потребностям.

Рис. 3. Стандартизация типов сервисов

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

С момента публичного представления первой версии UDDI функционирует общедоступный реестр UDDI Business Registry (UBR), который сейчас состоит из четырех географически распределенных реплицируемых узлов: Microsoft (западное побережье США), IBM (восточное побережье США), SAP (Европа) и NTT Telecom (Азия). Наиболее популярным применением UDDI все же остается организация закрытого сообщества взаимодействующих информационных систем либо внутри компании, либо в строго ограниченном кругу ее деловых партнеров. Очевидно, что частный реестр UDDI при этом является центральным звеном корпоративной сервис-ориентированной архитектуры.

5. Оркестровка

Весьма интересна терминология, связанная с веб-сервисами. Так, средства обмена сообщениями, с помощью которых несколько независимых агентов стремятся достичь желаемого состояния, получили название "хореографии", а взаимодействие сервисов - "оркестровки". Для "оркестровки" (т.е., по сути, описания бизнес-логики) были разработаны (с участием крупнейших вендоров, таких, как IBM, Microsoft, Oracle и BEA Systems) специальные средства программирования - BPEL4WS, XLANG, WSFL и др.

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

К ранним языкам определения бизнес-процессов путем комбинирования Web-сервисов относятся XLANG компании Microsoft (www.gotdotnet.com/team/ xml_wsspecs/xlang_c/default.htm) и Web Services Flow Language (WSFL) компании IBM (www-3.ibm.com/software/solutions/ webservices/pdf/WSFL.pdf). XLANG основан на языке WSDL; его основное назначение состоит в определении бизнес-процессов и организации обмена сообщениями между Web-сервисами. WSFL позволяет описывать как публичные, так и частные процессы. Определяется обмен данными, последовательность выполнения и отображение каждого шага процесса на конкретные операции.

6. Что такое Web-сервисы

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

Любой разговор о SOA невольно переходит на рассуждение о роли и месте Web-сервисов. Несмотря на то, что основные положения SOA сложились задолго до появления Web-сервисов, сегодня Web-сервисы занимают центральное место в SOA. Использование XML и Web-сервисов "поднимает SOA на более высокий уровень". Действительно, открытые стандарты, описывающие XML и Web-сервисы, позволяют применять SOA ко всем технологиям и приложениям, установленным в компании. Как известно, Web-сервисы базируются на широко распространенных и открытых протоколах: HTTP, XML, UDDI, WSDL и SOAP. Именно эти стандарты реализуют основные требования SOA - во-первых, сервис должен поддаваться динамическому обнаружению и вызову (UDDI, WSDL и SOAP), во-вторых, должен использоваться независящий от платформы интерфейс (XML). Наконец, HTTP обеспечивает функциональную совместимость. Наконец, сегодня Web-сервисы рассматриваются как эффективный инструмент для интеграции, в том числе для взаимодействия процессов, выполняемых в различных компаниях.

Для демонстрации возможностей SOAP может быть использована недавно вышедшая реализация SOAP Toolkit версии 2.0 производства Microsoft. Объект SOAPClient выступает в роли посредника (proxy), предоставляющего интерфейс Web-сервиса и позволяющего работать с ним как с обычным COM-объектом.

Рис. 4. Механизм взаимодействия клиента и сервера SOAP

Клиентское приложение создает экземпляр объекта SOAPClient. SOAPClient читает файлы описания методов Web-сервиса (на языках WSDL и Web Services Meta Language, WSML). Эти файлы могут храниться и на стороне клиента. Клиентское приложение, используя возможности позднего связывания методов объекта SOAPClient, вызывает метод сервиса. SOAPClient формирует пакет запроса (SOAP Envelope) и отправляет его на сервер. Можно применить любой транспортный протокол, но, как правило, используется HTTP.

Серверное приложение Listener (это может быть ISAPI-приложение или ASP-страница) принимает пакет, создает объект SOAPServer и передает ему пакет запроса. Помимо этого Listener обрабатывает HTTP-пакеты от клиента, отправляет клиенту пакеты с результатом работы сервиса, обрабатывает ошибки и использует функциональность SOAP-объектов. SOAPServer читает описание Web-сервиса, загружает описание и пакет запроса в деревья XML DOM. SOAPServer вызывает метод объекта или приложения, реализующего сервис. Результаты выполнения метода или описание ошибки конвертируются объектом SOAPServer в пакет ответа и отправляются клиенту. Объект SOAPClient проводит разбор принятого пакета и возвращает клиентскому приложению результаты работы сервиса или описание возникшей ошибки.

WSDL-файл - это документ в формате XML, описывающий методы, предоставляемые Web-сервисом, а также параметры методов, их типы, названия и местонахождение сервиса Listener. Мастер SOAP Toolkit автоматически генерирует этот документ, фрагмент которого приведен ниже: SOAP Envelope (Пакет) - это XML-документ, который содержит в себе запрос на выполнение метода или ответ на него. Удобнее всего рассматривать пакет как почтовый конверт, в который вложена информация.

Рис. 5. Структура SOAP-пакета

7. Четыре уровня адаптации SOA

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

Уровень 1.

Реализация отдельных Web-сервисов. Это начальный уровень развертывания SOA, на котором технологии Web-сервисов используются для разработки новых приложений или преобразования существующих, например, для интеграции с помощью WSDL-интерфейсов систем, написанных на С++, Cobol и Java. Здесь компании должны реализовать этапы создания и развертывания сервисов. Для создания предлагается инструментарий WebSphere Studio Application Developer, а также набор средств Emerging Technology Toolkit, который позволяет разработчикам опробовать новые решения в области Web-служб. Развертывание Web-сервисов поддерживается сервером приложений WebSphere Application Server.

Уровень 2.

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

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

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

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

Интеграция унаследованных систем. Здесь стоит выделить еще одну архитектурную концепцию, используемую для сервисно-ориентированной интеграции. Речь идет о концепции сервисной шины предприятия (enterprise service bus, ESB). Ее задача -- предоставить единый механизм передачи запросов и получения результатов сервисов, выполнения необходимых преобразований сообщений и транспортных протоколов (скажем, от SOAP на базе HTTP к SOAP на основе WebSphere MQ), обеспечения требований безопасности доступа и, что наиболее важно, управления потоком обращений к сервисам. Благодаря такому управлению выполняется нужная последовательность вызовов сервиса для реализации бизнес-процесса; определение процесса как серии обращений к сервисам поддерживается, например, в разработанном усиловиями IBM и Microcoft языке Business Process Execution Language (BPEL). Обратившись к схематичной иллюстрации шины ESB (рис. 3), можно увидеть, что этот подход решает одну из главных проблем интеграции -- проблему минимизации интерфейсов. Добавление нового сервиса к общей картине приведет к появлению одного и только одного дополнительного интерфейса для интеграции с остальными компонентами архитектуры.

Рис. 6. Модель сервисной шины

Все задачи интеграции, отображения бизнес-процессов компании в сервисы -- предмет реализации на втором и третьем уровнях перехода к SOA в трактовке IBM. На этих уровнях вступают в действие все четыре этапа жизненного цикла сервисов, и используется множество программных продуктов. Второй уровень -- это реализация SOA для ограниченного числа подразделений в компании. Здесь, на этапе создания к средствам разработки WebSphere Studio Application Developer добавляется система WebSphere Host Access Transformation Services. Для развертывания используется поддерживающий язык BPEL сервер интеграции бизнес-процессов WebSphere Business Integration Server Foundation и шлюзы CICS Tranaction Gateway или IMS Connect. Для использования полученных возможностей предлагается WebSphere Portal, а функции управления возлагаются на модули семейства Tivoli -- Access Manager и Monitoring for Transaction Performance.

Уровень 3.

Трансформация ИТ-инфраструктуры в масштабе предприятия. Здесь речь идет о сервисно-ориентированной интеграции приложений и процессов уже в масштабах всей компании, причем согласованный, сервисный подход к ИТ-инфраструктуре распространяется не только на внутренние подразделения, но и на партнеров и поставщиков. Здесь вступают в действие системы, обеспечивающие более глубокую детализацию разработки и интеграцию сервисов с учетом всех уже рассмотренных типов интеграции. IBM предлагает WebSphere Business Integration Modeler и Rational Rose XDE для этапа создания сервисов, WebSphere Business Integration Message Broker для развертывания, DB2 Information Integrator и Lotus Workplace для стадии использования. Управление такой полноценной средой SOA реализуется с помощью инструментов семейства Tivoli -- Identity Manager, Business System Manager и Monitoring for Business Integration, а также WebSphere Business Integration Monitor.

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

Уровень 4.

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

8. Проблемы SOA

Несогласованность стандартов. В области Web-сервисов сложились две группировки: одна включает IBM, BEA и Microsoft, а вторая -- Sun, Fujitsu и Oracle. Каждая из них продвигает свои разработки. Например, для управления транзакциями первая предлагает протокол WS-Transactions, а вторая -- WS-Transactions Management; для гарантированной доставки сообщений первая выпустила WS-ReliableMessaging, а вторая -- WS-Reliability. (Стоит отметить, что после анонсирования Microsoft Visual Studio Team System, а также предложений IBM по конкретным решениям, основанным на SOA, это противостояние стало минимальным, и можно ожидать продвижения в разработке единых стандартов, регламентирующих использование Web-сервисов).

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

9. Достоинства

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

Внедрение не требует полной перестройки корпоративной инфраструктуры. Предприятиям не нужно отказываться от привычных, хорошо себя зарекомендовавших приложений. Достаточно снабдить их соответствующими интерфейсами -- и Web-сервисы готовы. «Практическая ценность SOA для бизнеса заключается в возможности постепенного эволюционного развития корпоративной информационной инфраструктуры». Благодаря Web-сервисам бизнес-менеджеры могут гораздо активнее участвовать в создании корпоративных приложений. Правда, пока это лишь теоретическая возможность: необходимы специальные инструменты, позволяющие создавать сервисы без программирования. Но они уже начинают появляться. Например, компания UnitSpace выпустила ПО промежуточного слоя BCR. Оно позволяет адаптировать приложения к SOA, создавая Web-сервисы на основе заданных бизнес-аналитиками метаданных, без программирования. «Средства автоматического преобразования форматов позволяют приложениям обмениваться данными на основе их общей семантики, а выполнением бизнес-процессов управлять с помощью сценариев, написанных на стандартном языке BPEL.

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

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

Литература

1. Сергей Кузнецов. Обзор октябрьского 2003 года номера журнала Computer (IEEE Computer Society, Vol. 36, No. 10, October 2003).

2. Валентин Колесов Демонстрация работы SOAP на примере написания Web-сервер.

3. Отчет "Сервис-ориентированная архитектура" (Service Oriented Architecture. InfoWorld Research Report. 2005).

4. Хао Хи (Hao He) "Что такое сервис-ориентированная архитектура" (What is Service-Oriented Architecture?).

5. Клив Финкельштейн (Clive Finkelstein) "Корпорация: сервис-ориентированная архитектура" (The Enterprise: Service-Oriented Architecture (SOA)).

6. Джерими Уэстерман (Jeremy Westerman) "Сервис-ориентированная архитектура сегодня: введение в SOA" (SOA Today: Introduction to Service-Oriented Architecture).

7. Владимир Беленкович, Тимофей Горшков Логическая структура понятия сервисов в рамках SOA.

8. Елена Гореткина Непростой путь от Web-сервисов к SOA.

9. Даниил Фейгин Концепция SOA.

10. Наталья Дубова SOA: подходы к реализации.

Размещено на Allbest.ru

...

Подобные документы

Технология распределенных вычислений CORBA, взаимодействие компонентов и архитектура. Основное назначение CORBA и COM. Поддержка операционных систем, предлагаемые службы и масштабируемость. Формальное описание архитектуры и проблемы ее реализации.

курсовая работа , добавлен 02.12.2013


Объект CORBA и жизненный цикл серванта. Общий протокол межброкерного взаимодействия (GIOP). Связывание с языком высокого уровня. Статические и динамические вызовы. Применение технологии CORBA при построении распределенных информационных приложений.

курсовая работа , добавлен 23.12.2014


Сущность, развитие и применение СОМ-технологий, их достоинства, недостатки, терминология. Особенности СОМ-интерфейса, сервера, клиента, расширений. Локальные и удаленные серверы, их функции и реализация. Технология OMG CORBA и архитектура комплекса.

курсовая работа , добавлен 13.11.2011


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

лабораторная работа , добавлен 30.06.2009


Обзор существующих объектных архитектур. Архитектура программного обеспечения. Создание веб-сервиса "Библиотека", предоставляющего механизмы работы с данными на стороне клиентского приложения. WEB-сервис и трехуровневая архитектура в основе приложения.

лабораторная работа , добавлен 16.06.2013


Технология CORBA (Общая Архитектура Брокера Объектных запросов): интерфейс, управление объектами. Создание сервисного приложения, простейшего объекта. Установка связи между клиентом и серверным объектом. Массивы, обработка ошибок и устойчивость к сбоям.

реферат , добавлен 09.11.2011


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

контрольная работа , добавлен 15.06.2014


Агентно-ориентированная программная архитектура систем обработки потоковых данных. Обеспечение гибкости и живучести программного обеспечения распределенных информационно-управляющих систем. Спецификации программных комплексов распределенной обработки.

реферат , добавлен 28.11.2015


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

реферат , добавлен 22.06.2011


Назначение и цели создания системы. Разработка логической модели данных, выбор хранилища. Диаграмма классов для диспетчера и контент-менеджера, схема взаимодействия объектов системы. Описание программных модулей. Тестирование веб-базированной системы.