Сервис-ориентированная архитектура (SOA): опыт внедрения. Краткий обзор сервисно – ориентированной архитектуры (SOA)

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

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

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

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

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

Мировой рынок 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 (сервис-ориентированная архитектура).

В последнее время это стало эдаким 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):

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

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

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

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

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

Аннотация

Продолжительность курса

· Лекции – 45 мин;

· Ответы на тесты - 15 мин.

Теоретический курс

Понятие SOA

Согласно IT Gartner SOA SOA SOA SOA приложение».

Анатомия SOA

Слайды №6, 7

Рассмотрим логическую структуру SOA приложения. Как правило, подобное приложение на логическом уровне можно разделить на две большие части:

1. Бизнес – домен

2. IT – домен

Бизнес – домен включает в себя построение композитного корпоративного приложения и формирование бизнес-процессов из доступного набора сервисов.

IT – домен отвечает за создание сервисов, подключения существующих не – SOA приложений и т.д.

Если разделить SOA на уровни, то мы увидим следующие семь уровней:

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

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

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

Уровень 4: Уровень объединения (хореографии) бизнес процессов. На этом уровне определяется способы объединения сервисов, определенных на Уровне 3. Сервисы связаны в поток путем группировки (хореографии) и, следовательно, они действуют совместно как отдельное приложение. Для проектирования потоков приложения могут использоваться визуальные инструменты компоновки.

Уровень 5: Уровень презентации. SOA отделяет пользовательский интерфейс от компонентов, но без пользовательского интерфейса, как правило, обойтись нельзя. Пользовательский интерфейс позволяет вывести сервисы на уровень интерфейса приложения или презентации.

Уровень 6: Интеграция (ESB). Этот уровень допускает интеграцию сервисов путем предоставления набора таких возможностей, как интеллектуальная маршрутизация, посредничество протоколов и других механизмов преобразований, обычно описанных как ESB (Enterprise Service Bus) – корпоративная сервисная шина.

Уровень 7: Качество обслуживания (QoS) . Этот уровень предоставляет возможности для мониторинга, управления и поддержки таких аспектов качества обслуживания, как обеспечение безопасности, производительности и доступности. Он является фоновым процессом, использующим механизмы запросов и ответов, и инструменты, контролирующие общее состояние приложений SOA. Сюда включены все важные стандартные реализации WS - Management и других значимых протоколов и стандартов, реализующих качество обслуживания для SOA.

Стандарты SOA

Слайды №8, 9

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

Спецификации SOAP, WSDL и UDDI де-факто определяют стандартную инфраструктуру текущей технологии Web-сервисов. Две группы по стандартизации работают над официальными стандартами Web-сервисов – W3C и OASIS (Organization for the Advancement of Structured Information Standards).

W3C фокусируется на спецификациях инфраструктуры ядра технологии, а OASIS на высокоуровневой функциональности.

Simple Object Access Protocol (SOAP) – протокол обмена сообщениями, основанными на XML, определяет как Web - сервисы могут посылать сообщения друг другу. Это высокоуровневый протокол, который лишь определяет структуру сообщений и несколько правил по их обработке. SOAP не зависит от транспортного протокола, поэтому обмениваться SOAP - сообщениями можно через множество транспортных протоколов. В настоящее время чаще всего для передачи SOAP – сообщений в качестве транспортного протокола используется HTTP.

Web Services Definition Language (WSDL) – стандарт для описания Web - сервисов. Описание на WSDL содержит всю информацию необходимую для доступа и использования Web - сервиса, включая интерфейс Web сервиса. Описание на WSDL – это XML документ, содержащий набор определений, таких как типы данных, формат сообщений и т.д.

Таким образом, WSDL определяет стандартный описательный механизм для Web – сервисов, документ WSDL описывает, какую функциональность предлагает Web – сервис, как получить доступ и т.д. Документ WSDL может быть откомпилирован для создания proxy для клиентов, которые вызывают данный сервис (proxy позволяет клиенту «думать», что сервис расположен на той же машине, что и сам клиент).

Universal Description Discovery and Integration (UDDI) – «желтые страницы», в которых могут быть зарегистрированы Web - сервисы и их описания на WSDL. UDDI сам по себе Web - сервис и является реестром общего назначения, где могут быть зарегистрированы не только Web - сервисы.

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

Транспортные протоколы для Web-сервисов

В процессе разработки Web – сервиса, необходимо определить какие транспортные протоколы будет поддерживать Web-сервис для обмена сообщениями. В настоящее время, для транспортировки XML – сообщений чаще всего используется HTTP (основной протокол, используемый web-серверами и web – браузерами), а при реализации Web-сервисов на платформе Java может использоваться Java Messaging Service (JMS), который является частью спецификации J2EE. Web-сервис может поддерживать несколько транспортных протоколов, это обстоятельство находит свое отражение в WSDL файле сервиса.

Достоинства HTTP в том, что он используется повсеместно, гибкий и большинство сетевых экранов пропускают HTTP – сообщения. HTTP позволяет передавать не только WWW - документы, но и практически любые другие документы. HTTP также полезен для Web-сервисов, которые требуют синхронных двунаправленных соединений. Когда клиент вызывает метод Web-сервиса через HTTP, этот метод должен сразу же возвратить результат клиенту.

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

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

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

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

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

Форматы сообщений

Когда мы выбрали транспортный протокол для Web-сервиса, необходимо определиться с форматом собственно сообщений, которыми мы будем обмениваться. Формат сообщений описывает, как сообщение должно быть подготовлено к отправке по транспортному протоколу. Например, мы можем оформлять наши сообщения в SOAP – формате или в виде обычного XML. Независимо оттого, что мы выбрали – SOAP или XML, мы можем пересылать их через HTTP или JMS.

Web-сервис может поддерживать несколько транспортных протоколов и форматов сообщений.

Преимущества SOA

Слайд №10

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

У SOA есть и другие достоинства.

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

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

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

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

Проблемы использования SOA

Слайд №11

В целом идеи SOA понятны и производителям ПО и клиентам, однако нельзя сказать, что данная технология находится в зрелом состоянии. Недостаточно проработаны стандарты, не хватает инструментов управления. Как и часто бывает в таких случаях, сложилось группировки производителей программного обеспечения, разрабатывающих свои спецификации. В результате на роль «заполнителей дыр» в SOA сейчас претендует множество различных методов, но явного лидера нет. Сближение подходов намечается в рамках организация Web Services Interoperability (www.ws-i.org), которая пытается выработать некий общий знаменатель для технологии Web-сервисов. Она выпустила документ WS-I Basic Profile, определяющий требования к различным компонентам SOA, которые могут гарантировать их совместимость и прояснить тонкости использования Web-сервисов.

Перспективы и прогнозы

Аналитики с большим оптимизмом смотрят на будущее SOA и Web-сервисов. Так, по прогнозу компании Gartner, к 2008 г. более 60% предприятий будут использовать эту архитектуру в качестве основного принципа при создании ответственных бизнес-приложений.
В IDC подсчитали, что в прошлом году предприятия потратили на поддержку Web-сервисов 1,1 млрд. долл., а в 2008 г. израсходуют 11 млрд. долларов. Компания ZapThink, занятая исследованиями в области SOA, прогнозирует, что рынок инструментов для реализации Web-сервисов вырастет со 120 млн. долл. в 2003 г. до 8,3 млрд. долл. в 2008 г. Аналитики объясняют такой подъем тем, что SOA, позволяющая снизить расходы на IT , становится главной стратегией при решении проблем интеграции разнородных систем. Отношение предприятий к SOA становится более серьезным, и они переходят от экспериментов к реальным внедрениям.

Понятие Web – сервиса

Слайд №13

Web - сервисы можно рассматривать как «plug and play» приложения. Web -сервис представляет собой часть информационной системы или бизнес-процесса, к которой можно обратиться в том числе и через Интернет с целью сборки требуемой информационной системы.

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

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

Основными возможностями, предоставляемыми Web-сервисами, являются:

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

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

· Доступ к Web –сервису можно осуществлять как через интранет, так и через Интернет.

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

Виды Web – сервисов

По формату сообщений, Web – сервисы разделяются на:

1. Web – сервисы, основанные на сообщениях SOAP.

2. Web – сервисы, основанные на технологии Representational State Transfer (REST).

3. Web – сервисы, основанные на XML-RPC.

Так как для приложений уровня предприятия требуется такие возможности как обеспечение безопасности и т.д., то, как правило, для таких целей выбирают Web-сервисы, обменивающиеся SOAP-сообщениями.

По способу обработки входящих сообщений Web - сервисы могут быть:

1. Синхронные

2. Асинхронные

Список источников

1. Об использовании BPMS - http://www.bpms.ru

2. Демонстрация BPMS - http://www.unify.ru/demo/bpm/index.html

3. Материалы исследований компании ZapThink - http://www.zapthink.com

4. Материалы о механизмах интеграции компании Intersoft Lab -

http://www.iso.ru/journal/articles/themes/17

5. Техническая библиотека компании BEA - http://dev2dev.bea.com/soa/

6. Техническая библиотека компании Sun - http://java.sun.com/webservices/index.jsp

7. Техническая библиотека компании IBM –

http://www-128.ibm.com/developerworks/ru/views/webservices/libraryview.jsp

8. mig_ssdoc\\$/ПРОИЗВОДСТВО SOA/Архитектура/Презентация платформы v2.ppt

9. mig_ssdoc\\$/ПРОИЗВОДСТВО SOA/Архитектура/Архитектура системы v2.doc

Приложение 1

Рисунок для иллюстрации архитектуры фронт – офисного решения Diasoft.

Аннотация

Данный документ предназначен для проведения лекционных занятий по теоретическому курсу "Основы сервисно – ориентированной архитектуры".

Требования к знаниям слушателей:

· Знание основ архитектуры построения распределенных многозвенных приложений;

По итогам обучения, слушатели должны:

· Получить представление о принципах построения приложений в SOA;

· Узнать о ключевых технологиях, применяемых в SOA;

· Иметь представление о сервисах, как основных строительных элементах SOA приложений;

· Узнать об использовании корпоративной сервисной шины ESB для интеграции Web - сервисов;

· Получить информацию о системах управления бизнес – процессами (BPMS).

· Получить основные сведения об архитектуре фронт – офисного решения Diasoft.SOA

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

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

Продолжительность курса

· Лекции – 45 мин;

· Ответы на тесты - 15 мин.

«Основы сервисно – ориентированной архитектуры»

Теоретический курс

1. Краткий обзор сервисно – ориентированной архитектуры (SOA)..... 4

1.1. Понятие SOA................................................................................................................... 4

1.2. Предпосылки возникновения SOA........................................................................... 4

1.3. Эволюция архитектуры корпоративных IT систем............................................... 4

1.4. Анатомия SOA................................................................................................................ 5

1.5. Стандарты SOA.............................................................................................................. 6

1.6. Преимущества SOA........................................................................................................ 8

1.7. Проблемы использования SOA................................................................................. 8

1.8. Перспективы и прогнозы............................................................................................. 9

2. Инфраструктура для приложений в SOA.............................................. 9

2.1. Элементы инфраструктуры для реализации приложений в SOA.................... 9

2.2. Понятие Web – сервиса................................................................................................ 9

2.3. Схема регистрации и поиска Web – сервисов....................................................... 10

2.4. Механизм вызова Web – сервисов и конвертация данных \ протоколов с использованием ESB................................................................................................................................... 11

2.5. Использование ESB для интеграции приложений.............................................. 11

2.6. BPEL - язык описания бизнес - процессов............................................................. 12

2.7. BPMS – система управления бизнес - процессами.............................................. 14

3. Архитектура фронт - офисного решения Diasoft................................. 17

3.1. Особенности фронт – офисного решения Diasoft............................................... 17

3.2. Архитектурные слои фронт – офисного решения Diasoft................................. 18

Список источников..................................................................................... 19

Приложение 1............................................................................................... 20

Краткий обзор сервисно – ориентированной архитектуры (SOA)

Понятие SOA

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

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