Service Oriented Architecture (SOA) - это новая парадигма проектирования распределенных интегрированных систем. Согласно SOA любые части информационных систем имеющие функциональность рассматриваются как службы (service providers, провайдеры служб), которые предоставляют свою функциональность другим частям системы посредством вызовов их функций. Службы являются компонентами, которые могут быть найдены и вызваны через локальную сеть или Internet. При этом различные службы могут организовываться (orchestrate) для совместного выполнения определенной задачи. SOA обеспечивает концептуальные архитектурные шаблоны и платформы для таких систем. Обычно архитектура таких систем и потоки данных в них близки к структуре бизнес-подразделений, использующих их, и взаимодействий между ними. В некоторой степени происходит соединение информационных технологий и бизнес-процессов на концептуальном уровне. Такое слияние положительно влияет на понимание информационных систем представителями бизнеса (концепция службы более наглядна чем термины "репликация", или "удаленный вызов процедуры"), и на понимание бизнес-процессов разработчиками системы. В качестве платформы для SOA-приложений обычно используются web-службы. Однако, не все информационные системы, построенные на основе web-служб, соответствуют SOA, и SOA не обязательно должна базироваться на технологии web-служб. Концепция SOA впервые была описана в 1996 году, но только в последние годы на волне интереса к web-службам стала широко известной. К этой волне популярности приложило руку и Microsoft - в 1999 году Steve Ballmer озвучил концепцию "software as service", получившую свое воплощение в технологии.NET и web-службах. Поддержка web-служб встраивается во многие продукты Microsoft - BizTalk Server, MapPoint Server, SQL Server 2005 (Yukon), Office 2003.

Don Box - один из архитекторов новой инфраструктуры Microsoft для межпрограммного обмена сообщениями Indigo выделил 4 основных принципа SOA:

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

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

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

Совместимость служб основана на политиках (policy). Применение технологий, таких как WS-Policy, предоставляют декларативные и программные способы описания политик. Политики применяются как для служб, так и для клиентских приложений. Примером политики может быть требование на шифрование обмениваемых данных.

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

Этапы развития архитектуры программного обеспечения

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

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

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

отсутствие встроенных средств безопасности

Архитектура, основанная на компонентах, (CORBA, COM/DCOM) сняло часть проблем - снизило степень детализации и улучшило ситуацию с повторным использованием компонент. Компонентные технологии обеспечивали языки описания интерфейсов (к примеру, IDL) и средства для локального и удаленного вызова компонент.
SOA позволяет проектировать и создавать приложения, предоставляющие другим приложениям удаленно вызывать их методы через опубликованные интерфейсы, и возможность найти эти службы и описания интерфейсов. На схемы на примере web-служб видно 3 основные роли в SOA - службы (service providers), клиенты служб (service consumers) и брокеры (brokers). Доступ к службам происходит через сеть по стандартным протоколам. Сами службы описываются на стандартном языке (контракт службы) и публикуют эту информацию при помощи брокера. Службы разделяют свой интерфейс и его реализацию. Для вызова службы клиентскому приложению нужно только описание интерфейса службы - информация же о реализации службы не нужна клиентам. Реализация службы может меняться, не затрагивая клиентов и без необходимости предоставлять клиентам новую версию описания службы - в этом и проявляется низкая связанность частей системы (loose coupling). Другим преимуществом разделения интерфейса и реализации является возможность выбора клиентом службы из нескольких служб с одинаковым интерфейсом путем простого указания адреса нужной службы. В этом скрыта возможность для расширения и масштабирования системы после ее создания. В систему можно добавлять новые службы или новых клиентов служб не нарушая уже существующую функциональность. Причем для добавления добавления новой функциональности к системе не нужно иметь доступ к ее исходному коду. Для обеспечения такой независимости от реализации при использовании web-служб нужно избегать использования типов данных, привязанных к определенной технологии (например, вместо типизированных DataSet платформы Microsoft .NET использовать сущностные классы или специально созданные объекты переноса данных (DTO)) и расширений WS-*, пока имеющих различия реализаций на разных платформах.
Брокеры хранят информацию о службах и предоставляют эту информацию клиентам.
Web-службы являются наилучшей технологией, на котором основывается SOA. Поиск web-служб происходит в UDDI-каталоге, интерфейс службы описан на WSDL, а вызов происходит по протоколу SOAP. Так как web-службы базируются на стандартизированных технологиях, они работают в кросс-плафторменных средах и не зависят от языка реализации.

Характеристики service oriented architecture. Информационные системы, построенные согласно SOA, обладают следующими характеристиками:

основанность на индустриальных стандартах. SOA использует технологии, разработанные совместно Microsoft, IBM, SUN, BEA, Oracle, W3C. Это освобождает от привязки к конкретной платформе или поставщику программных продуктов. Различные части системы могут быть разработаны на различных языках программирования и работать на разных платформах

низкая связанность (loose coupling) частей системы. Клиенты в SOA системах могут разрабатываться в полной независимости от служб, используя только их опубликованный интерфейс. Из-за разделения интерфейса и реализации служб клиентские приложения подключаются к службам с помощью позднего связывания (late binding). Низкая связанность обеспечивает лучшую способность систем к их расширяемости: изменения в функциональности в службе не должно затрагивать клиентов, а при добавлении новых типов данных средства разработки берут на себя часть работы. Низкая связанность также способствует инкрементному и итеративному подходу к разработки ПО, из-за отсутствия трудностей реализации функцинольности службы за несколько итераций

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

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

Типы служб. Службы на основе их функциональности можно условно поделить на пять типов:

службы доступа к данным , предоставляющие чтение и изменение данных (CRUD-функции). Они скрывают реализацию доступа к реальным источникам данных и предоставляют единый унифицированный интерфейс для доступа к данным вне зависимости от количества и вида используемых источников данных. Для обмена данными могут использоваться специально созданные сущностные объекты, XML данные или же объекты, инкапсулирующие таблицы БД (например, объекты DataSet платформы.NET). Этот вид служб SOA самый легкий в реализации и чаще всего используется в приложениях

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

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

низкоуровневые вспомогательные службы отвечают за аутентификацию и авторизацию, мониторинг, поиск служб, регистрацию ошибок, вспомогательные функции, используемые в других службах. Часто их называют общие службы (common services) или службы инфраструктуры предприятия (interprise infrastructure services)

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

Степень детализации служб (service granularity). Детализация служб относится к масштабу функциональности, предоставляемой службой. На основе функциональности по количеству данных, получаемых и отправляемых службой, можно разделить их на службы с мелкой детализацией (fine-grained), грубой детализацией (coarse-grained) и композитные (composite).
Службы с мелкой детализацией осуществляют прием и отсылку данных небольшими порциями информации и и на каждую их функцию приходится небольшое количество функциональность. Дополнительно может возникнуть необхоимость сохранения с состояния службы между ее вызовами.
При грубой детализации происходит обмен большими порциями информации и каждая функция реализуют б о льшую функциональность. При этом передаваемые данных часто имеют составную структуру и используются специально созданные объекты переноса данных (data transfer objects).
Функции с мелкой детализацией обычно вызываются не реальными приложениями, а другими службами - композитными или с грубой детализацией, использующими высокосоростные сетевые соединения. При вызове служб с мелкой детализацией напрямую клиентскими приложениями из-за большого количества обмениваемых сообщений (особенно при низкой скоростью соединения) суммарное время вызова функций возрастает из-за накладных расходов.
Композитные службы используют для своей работы службы с мелкой и грубой детализацией, делегируя им реальную работу и осуществляя контролирующую функцию и сбор информации.
Microsoft Indigo. Новая версия операционной системы Windows "Longhorn" будет включать в себя инфраструктуру для разработки распределенных систем под кодовым названием "Indigo", основанная на.NET. Indigo предоставляет общую программную модель для использования web-служб, .NET remoting, System.Messaging и.NET Enterprise Services. Indigo входит в состав WinFX (новой программной моделью Windows) и будет поставлятся так же и для операционных систем Windows XP и Windows 2003. Основными подсистемами Indigo являются сервисная модель, коннектор, хостинговое окружение и службы.

Архитектура Indigo

Сервисная модель Indigo отвечает за связывание кода, отвечающего за обработку сообщений, и приходящих сообщений. На нее возложены функции поддержки транзакций, обеспечения безопасности передачи сообщений и их гарантированную доставку. Для упрощения разработки активно применяется декларативный подход.
Коннектор обеспечивает соединение между службами, основанное на SOAP и метаданных служб. Скрывая детали реализации и оперируя такими понятиями как порт, канал и сообщение он позволяет создавать высокопроизводительные приложения, независящие от транспортных протоколов, обеспечивающие безопасность, регулирование нагрузки и надежность передачи сообщений и способных настраиваться на различные конфигурации сетей (SSL, прокси-серверы, файрволы и пр.). Для этого в коннектор входит кодировщик, конвертирующий сообщения в данные, передаваемые по конкретному транспортному протоколу, и обратно. Для гарантированной доставки сообщений можно применять одну из двух моделей гарантированной доставки: экспресс, при которой в памяти содержится буфер сообщений, доставка которых еще не подтверждена, и надежный, при котором этот буфер находится на жестком диске.
Хостинговое окружение. Сервисная модель Indigo и коннектор могут быть загружены в любой домен приложения. Окружение хостнига было разработано для использования Indigo в максимально большом количестве систем хостинга (dllhost.exe, svchost.exe, IIS и пр.).
Системные службы и службы сообщений. Для обеспечения функциональности служб Indigo использует специальные службы. В качестве пример системных служб можно привести службы для обеспечения транзакций. Службы сообщений обеспечивают расширенную функциональность для очередей сообщений и поддержку событий.
Как мы видим все подсистемы можно поделить на 2 уровня - на высокоуровневые слой, имеющий удобный для разработки приложений интерфейс, и низкоуровневый слой, обеспечивающий б о льшую производительность и контроль над тонкостями реализации.
Indigo позволяет создавать службы двух видов: web-службы и RemoteObject службы. Web-службы в Indigo представляют собой традиционные asmx службы ASP.NET, соответствующие SOAP 1.2 и дополненные расширенными возможностями: поддержкой распределенных транзакций, гарантированной доставкой сообщений, поддержкой web-serivce farms для увеличения масштабируемости и возможностью обмена сообщениями между службами и клиентами в обоих направлениях.
Службы RemoteObject являются улучшенной версией.NET remoting, позволяющей создавать экземпляры удаленных объектов или удаленно вызывать их методы. Обновления и улучшения коснулись улучшенной поддержки SOAP, импорта и экспорта метаданных, аутентификации, шифрования, распределенных транзакций и автоматической активации.

Обзор терминологии SOA

Часть 1. Сервис, архитектура, управление и бизнес-термины

Бертран Портье (Bertrand Portier)
Опубликовано 25.06.2008

Серия контента:

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

Организационное замечание

Перечисленные ниже термины не выстроены по алфавиту, равно как и по степени важности. Они организованы скорее в блочном стиле. Мы начинаем с "сервиса", поскольку это фундаментальное понятие в рамках SOA. На этом понятии мы строим определения таких терминов, как "архитектура", "управление" и "бизнес". Во многих случаях мы разбиваем объемные термины на их составные компоненты.

Сервис

Сервисы являются, несомненно, сердцем сервис-ориентированной архитектуры: сам термин сервис широко используется. Однако разные люди понимают его по-разному, а потому вопрос "Что такое сервис?" часто приводит к долгим спорам. Мне приходилось слышать, как люди разговаривают о бизнес-задачах, бизнес-сервисах, функциях приложений, технических сервисах и сервисах из области инфраструктуры. Позвольте, я дам вам определение, основанное на IBM Rational® Method Composer Plug-in for SOA Governance и на IBM Rational® Unified Process for Service-Oriented Architecture. Дополнительную информацию вы найдете в .

"Сервис – это видимый ресурс, выполняющий повторяющуюся задачу и описанный внешней инструкцией".

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

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

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

Также важно учитывать, что не все является сервисом. Есть такие ИТ-функции, которые размещать в качестве сервисов смысла нет. Такие аналитические техники, как IBM Service-Oriented Modeling and Architecture (SOMA), помогают определять соответствие сервисов перечисленным выше идеям. Все эти моменты (включая все выделенные термины из данного раздела) мы подробно рассмотрим в данной статье.

Архитектура

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

На форуме Open Group Architecture Forum (TOGAF) есть два определения архитектуры в зависимости от контекста:

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

Эти два определения критически важны для понимания "A" (архитектуры) из аббревиатуры SOA. Заглянув глубже, мы видим также, что архитектура необходима для следующего:

Разработка и моделирование на разных уровнях абстракции
Отделение инструкции от реализации
Построение гибких систем
Проверка на соответствие бизнес-требованиям
Анализ объема изменений при появлении новых требований
Проверка на соответствие правилам

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

Вот определение из Википедии:

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

Главная цель создания архитектуры предприятия – согласование бизнес-стратегии и вложений в сектор ИТ. Таким образом, архитектура предприятия позволяет от общей бизнес-стратегии перейти на уровень ниже, к лежащей в ее основе технологии."

Вы можете отнести "архитектуру" на уровень проектов, а "архитектуру предприятия" - на уровень организаций. Отметьте также упоминания о процессах, информационных системах, персонале, целях, стратегии и бизнес-ориентировке ИТ.

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

Ориентация на сервисы

Как написано в техническом обзоре IBM SOA foundation, "... ориентация на сервисы – это путь интеграции бизнеса как набора связанных сервисов." Больше информации об IBM SOA foundation вы найдете в .

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

Эталонная модель SOA foundation

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

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

Рисунок 1. Эталонная модель SOA foundation

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

В IBM SOA foundation SOA определена следующим образом:

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

SOA обладает следующими характеристиками:

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

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

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

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

Она не зависит от технологий, на которых построена. Как вы увидите в разделе "Модельно-управляемая архитектура" (Model-Driven Architecture - MDA) во второй статье данной серии, это разделение важно.

Рисунок 2. Структура решений SOA

Структура состоит из 5 функциональных слоев (снизу вверх):

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

Управление

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

Этот раздел содержит определения из IBM Rational Method Composer Plug-in for SOA Governance. Здесь определяются термины "управление", "ИТ-управление", "SOA-управление", а также определяется разница между управлением, руководством и соответствием. Тут же описываются проблемы, стоящие перед SOA-управлением. Более подробную информацию о Rational Method Composer вы найдете в .

Управление

"Под управлением мы подразумеваем:

Установление цепочек ответственности, полномочий и связей, чтобы уполномочить людей (права на принятие решений)
Установление механизмов для измерений, расчетов и контроля с тем, чтобы люди могли выполнять свои обязанности в рамках своей ответственности

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

Частью любого управленческого решения является соответствие организационным правилам соответствия. Соответствие - это документированное доказательство того, что управление имеется и реализуется: решения документируются, а правила принятия решений соблюдаются."

ИТ-управление

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

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

SOA-управление

"SOA-управление – это надстройка над ИТ-управлением, ориентированная на сервисы и прочие продукты жизненного цикла SOA."

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

"SOA-управление предназначено для решения следующих проблем:

Какие новые организационные должности и структуры нужны для идентификации, разработки и совместного использования сервисов?
Какие метрики поддерживают вложение средств, обслуживание, жизнеспособность и совместное использование сервисов?
Как бизнесу решить вопрос об инвестициях в создание и обслуживание сервисов?
Что такое зрелость производства в области сервис-ориентированности?
Какие необходимы образование, обучение или наставничество?"

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

Жизненный цикл сервиса

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

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

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

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

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

В определении жизненного цикла SOA IBM SOA foundation отмечает четыре фазы:

Модель состоит из бизнес-анализа и разработки (требования, процессы, цели, ключевые показатели продуктивности) и ИТ-анализа и разработки (определение и спецификация сервисов).
Сборка состоит из программирования сервисов и построения сложных приложений.
Размещение состоит из размещения приложений и средств времени исполнения, таких как Enterprise Service Buses (ESB).
Руководство состоит из поддержки операционной среды, мониторинга производительности сервисов и слежения за соблюдением сервисных политик.

Определенные выше SOA-управление и процессы поддерживают эти четыре фазы. Это отображено на рисунке 3.

Рисунок 3. Жизненный цикл SOA

Бизнес

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

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

Ориентация на бизнес

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

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

Компонентное представление бизнеса

сайтponent Business Model® - стратегический метод, позволяющий компаниям фокусироваться на своих ключевых сферах деятельности – на том, чем компания отличается от своих конкурентов, на отслеживании потребления ресурсов и установлении лучшей связи бизнеса со сферой ИТ. В вы найдете дополнительную информацию о Component Business Model. С помощью и благодаря ориентации на сервисы достигается интеграция и взаимодействие этих компонентов бизнеса, а также гибкость, благодаря которой можно проводить аутсорсинг компонентов: у каждого из компонентов бизнеса есть своя уникальная цель, а сообщаются они между собой посредством набора бизнес-сервисов, которые они поставляют другим компонентам либо получают от других компонентов. Это можно рассматривать как часть "бизнес-архитектуры".

Бизнес-моделирование

Бизнес-моделирование определяется IBM Rational Unified Process® следующим образом:

"Дисциплина Rational Unified Process Business Modeling предоставляет точное руководство для описания с помощью набора подходов и техник, на разных уровнях формализации "текущего" или "желаемого" бизнеса".

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

SOA – долговременная стратегия реорганизации бизнеса и ИТ-систем, цель которой - быстрое реагирование на перемены. В есть ссылка на журнал IBM Systems (том 44, номер 4), рассказывающий о SOA, в котором вы найдете более подробное рассмотрение связанных с бизнесом сторон сервис-ориентированного мышления.

Бизнес-процесс

Бизнес-процесс – это последовательность действий, дающая полезный результат.

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

Бизнес-деятельность и задачи

Бизнес-деятельность и задачи – это элементы, которые, будучи связаны, образуют бизнес-процессы.

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

Моделирование бизнес-процессов

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

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

Задачи для людей

Довольно часто в процессах требуется человеческое вмешательство (например, утверждение командировки или кредита). Такие задачи при моделировании бизнес-процесса определяются как ручные, и для каждой задачи назначается определенная роль. После размещения для выполнения процессов SOA потребуется поддержка задач, выполняемых людьми. Такие продукты, как, например, IBM WebSphere Process Server, предоставляют пользователям списки ожидающих их задач для людей. При их комбинировании с такими продуктами, как IBM WebSphere Portal и Lotus Sametime, пользователи также могут сотрудничать между собой и оповещать систему о принятых ими решениях, чтобы система могла продолжать выполнение процессов. Этот человеческий фактор критически важен для успеха SOA.

BPEL

IBM, Microsoft и другие компании участвовали в разработке языка Business Process Execution Language (BPEL) for Web services specification (язык выполнения бизнес-процессов для создания спецификаций Web-сервисов), являющегося средством формального описания бизнес-процессов и протоколов взаимодействия.

Отрасли

В разных сферах деятельности и отраслях бизнес-процессы могут иметь свою специфику, как, например, в страховании. Отраслевые бизнес-процессы определяются промышленными консорциумами. Например, TeleManagement Forum определяет enhanced Telecom Operations Map (eTOM) для телекоммуникационной отрасли. Кроме того, компании, чтобы выделиться среди конкурентов, могут внедрять свои собственные бизнес-процессы, основанные на проверенных моделях, таких как IBM Industry Models. В приведена ссылка на IBM Insurance Application Architecture (IAA), которая является примером IBM Industry Models.

Управление бизнес-процессами

Управление бизнес-процессами (Business Process Management - BPM) занимается полным жизненным циклом бизнес-процессов с целью повышения их эффективности, гибкости и управляемости.

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

Заключение

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

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

Я хотел бы поблагодарить моих коллег из IBM, которые внесли большой вклад в сервис-ориентированную архитектуру и описанные в статье идеи. Особую благодарность выражаю Ричарду Джонсону (Richard D. Johnson) и Стиву Киндеру (Steve Kinder) за рецензию на эту статью.

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

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

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

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

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

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

Развитие SOA

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Основные принципы SOA

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

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

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

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

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

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

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

Преимущества и сложности подхода SOA

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

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

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

Для унификации описания процессов все чаще используется Business Process Executive Languages (BPEL) - язык исполнения бизнес-процессов, и его место в SOA очень важно, поскольку такое описание является необходимым условием для внедрения SOA. При этом оно должно быть понятным как владельцам бизнес-процессов, так и информационным системам. В данном случае использование нотации eEPC (событийной цепочки управления бизнес-процессом) для уровня бизнеса с последующей трансформацией полученных моделей в BPEL позволяет минимизировать затраты на формализацию процессов и их автоматизацию. На основании языка BPEL система автоматизации будет вызывать требуемые описанные сервисы, чтобы передать им необходимую для выполнения информацию.

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

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

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

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

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

Заключение

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

Первые шаги к SOA

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

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

Назовите меня троллем, если хотите, но я серьезно - как точно новый тренд SOA отличается от архитектуры клиентского сервиса, которую я строил 15 лет назад? Я продолжаю слышать SOA, но я не вижу, как это отличается от того, что мы всегда делали. Назад 10 лет назад, у компании было несколько клиентов (на нескольких языках), которые говорили с одним и тем же сервисом. Это был не XML (это был двоичный протокол под названием Microsoft DCOM), и не было автоматического обнаружения через WSDL, но это нормально, так как чтение документов было так же просто. Наша система была даже "открытой" в том смысле, что мы ее достаточно документировали, чтобы третьи стороны могли говорить с нашими сервисами. Мы не были пионерами - каждая другая компания, которую я знала 10 лет назад, делала то же самое. Единственная разница, которую я вижу между тогда и сейчас, заключается в том, что теперь в Интернете есть одна служба, а 10 лет назад каждый клиент будет размещать свой экземпляр службы. Но это не проблема архитектуры, где физическая жизнь службы прозрачна для всех, кто пользуется службой.

Так что же такое SOA, которая отличается от того, что мы делали годами? Является ли SOA просто маркетинговым термином, представляющим собой наилучшую практику, которая на самом деле стала распространенной давным-давно? Или я немного упустил SOA, что отличается от того, что мы делали все это время?

10 ответов

Забудьте о XML. Забудьте о WSDL. SOA - это не технология, которую вы можете купить, хотя она часто продается именно так.

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

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

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

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

Позвольте мне использовать знаменитого мальчика-бичевателя Integration Hell: Telco.

Вернувшись в 90-е годы, компании сотового телефона были в изобилии в моем районе, почти так же многочисленны, как и реселлеры на большие расстояния, которые стали возможными благодаря дерегулированию коммуникаций середины 90-х. Ну, время продолжается, и Bell Atlantic становится электростанцией Verizon и поглощает компанию после компании (и хотя бы одного Baby Bell). У каждой из этих компаний есть технологии на башнях, в коммутационном оборудовании, в биллинговых системах, которые ПОЛНОСТЬЮ несовместимы друг с другом.

Итак, компания уходит и говорит, хорошо, у нас есть эти модели для того, как мы занимаемся бизнесом, давайте дружеское, последовательное лицо на ВСЕХ наших технологиях в виде WSDL/SOAP/XSD - на каждом языке и в системе мы сегодня могут быть сопряжены с этим! Медленно, но верно, компания создает все системы, способные сообщать о возможностях, быть опрошенными для загрузки и выставления счетов, а также подвергать будущих виджетов использованию в манерах, которые еще не были учтены.

Любой может создать SOA-клиент. Любой, у кого есть wget и текстовый редактор. И каждый может анализировать результаты (XML).

Это принципиально отличается от прошлых клиент-серверных архитектур. На днях я просто поговорил с кем-то о взаимодействии систем Cobol и Smalltalk с архитектурой SOA. Это легкая проблема для решения. Скажите, вы можете сказать то же самое для своих систем DCOM.

SOA ничего, кроме способа дизайна , в котором модули взаимодействуют друг с другом через "сервисы". Это просто, и теперь следующий вопрос: что такое "сервис" и каково его отличие от обычного "метода"?

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

SOA не имеет ничего общего с конкретной технологией, это всего лишь особый способ проектирования.

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

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

Возможно, именно в "дорожной карте" для корпоративных возможностей или набора для каждого решения станет совместимым сервисом по мере завершения решений и ввода службы. Для этого, возможно, команды разработчиков будут применять модульный/компонентный подход к построению soluton (возможной службы), чтобы упростить включение решения в качестве службы в сервис-ориентированную архитектуру.

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

SOA - это подход или идея. Это не каркас или инструмент. Когда WDSL и EJB получают имя-падение, это часто забывается... так же, как идея SOA совсем не нова.

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

Аналогия: Игрушки строятся с использованием строительных блоков Lego.

Большинство ответов здесь, по-видимому, говорят о том, что SOA (Service Oriented architecture) относится к созданию приложения стандартизованным образом, чтобы другие приложения могли взаимодействовать с ним независимо от платформы.

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

Конечно, при разработке приложения вы не можете гарантировать, что он будет совместим с кросс-платформой. Возьмем, например, stock Trading systems . Они используют Fix protocol для передачи сообщений. Ожидаете ли вы теперь вернуть данные в формате XML, чтобы он мог быть так назван SOA-совместимым? Точно нет! SOA - это архитектурный подход, который может помочь вам decouple your application/services и позволить им взаимодействовать друг с другом. Магистраль SOA - это ESB (Enterprise Service Bus) , которая используется для передачи данных из одной службы в другую. Архитектура SOA должна заботиться о преобразованиях форматов. Например -

FIX(Service 1) -> (XML ---ESB---> XML) -> JSON (Service 2)

Эти модули преобразования обычно называются adapters и обычно являются частью пакета SOA. Для получения дополнительной информации обратитесь к другому ответу -

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