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

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

Предпосылки

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

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

Рис. 1. Прямая интеграция приложений

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

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

Характеристики SOA

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

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

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

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

Многие авторы подчеркивают, что идея SOA не нова и, по существу, не связана с конкретными технологиями реализации, что ее зачатки угадываются уже в CORBA и в программном обеспечении промежуточного слоя на базе обмена сообщениями (message oriented middleware), что ее нельзя отождествлять с Web-сервисами, которые представляют собой совокупность технологий и стандартов. Все это верно, однако именно появление Web-сервисов сделало SOA реальностью. Язык описания интерфейсов в CORBA не обеспечивает той независимости от платформ, которая требуется для построения SOA, а потому данная модель позволяет реализовать только сильно связанную интеграцию компонентов. С появлением XML был открыт путь к созданию нейтральных к платформе реализации интерфейсов. Основанный на XML язык описания Web-сервисов WSDL и использование XML для обмена сообщениями между сервисами обеспечивают тот универсальный механизм взаимодействия разнородных компонентов, без которого невозможно реализовать SOA.

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

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

Платформа реализации SOA

Как отмечают аналитики компании ZapThink, которая специализируется на вопросах SOA, и заказчикам, и поставщикам необходимо осознать следующий принципиальный момент: SOA — это не очередной вариант распределенной вычислительной среды, который, достигнув стадии зрелости, будет существовать параллельно с другими возможными вариантами [2]. В перспективе любая архитектура ИТ-среды — клиент-серверная, многозвенная, построенная на базе шины сообщений и т.д. — должна рассматриваться в контексте ориентации на сервисы. SOA — это более высокий уровень абстракции, который дает возможность объединить различные архитектурные стили и модели организации распределенных систем на разных платформах с помощью слабо связанных интерфейсов и асинхронного взаимодействия между ними.

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

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

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

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

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

Зеленые блоки символизируют рынки систем, связанных с Web-сервисами. Они также находятся в переходном состоянии, поскольку появились сравнительно недавно и с течением времени станут частью других сегментов рынка сервисно-ориентированных систем. В некоторых случаях этот переход уже фактически завершен, например, для такой категории продуктов, как СУБД, рассчитанные на непосредственную работу с XML-данными. Поставщики этих решений проявляли большую активность в 2002 году, но уже к середине 2003 года большинство из них либо вообще вышли из игры, либо были приобретены другими компаниями, либо переориентировали свою деятельность на другие стратегические направления, такие как оперативные хранилища данных или системы управления контентом.

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

SOA по версии «Голубого гиганта»

Рынок средств реализации SOA еще только формируется, а потому ни один из современных поставщиков программного обеспечения пока не может предложить решений с полным спектром необходимой функциональности [2]. Аналитики ZapThink выделяют несколько компаний, которые уже имеют солидный продуктовый багаж в тех областях, на базе которых развивается переход к SOA, и уже проделали немалую работу по поддержке в своих системах стандартов Web-сервисов и принципов SOA в целом. Среди них компании НР, IBM, Microsoft и Computer Associates, а также ряд игроков с более сфокусированной направленностью, включая BEA Systems, Ascential Software, Sybase, Progress Software, webMethods, Software AG.

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

IBM предлагает четырехуровневый подход к адаптации принципов SOA [3]. Каждый из уровней может включать несколько этапов жизненного цикла сервиса, которых также четыре: создание (build), развертывание (deploy), использование (use), управление и защита (manage and secure).

Четыре этапа жизненного цикла сервиса

Создание сервисов подразумевает как построение бизнес-модели будущего приложения в SOA, так и непосредственную разработку сервисов как многократно используемых компонентов с общими, публикуемыми интерфейсами. Для этого разработчики должны иметь инструментарий, обеспечивающий поддержку принципов SOA и необходимых стандартов для проектирования модели приложения, разработки сервиса в целом и входящих в него объектов, а также тестирования приложения в сервисно-ориентированной среде. Для SOA необходима модель компонентной разработки, которая позволит создавать не только новые сервисы, но и включать в единую сервисно-ориентированную среду уже существующие на предприятии приложения и программные модели. Средства разработки, предлагаемые IBM, обеспечивают интеграцию в SOA программных компонентов, реализованных в архитектуре CORBA или в среде с промежуточным слоем на базе WebSphere MQ, унаследованных приложений, управляемых с помощью монитора транзакций CICS, и т.д.

Перспективной для SOA может быть новая архитектура разработки на базе моделей (Model-Driven Architecture, MDA), предложенная консорциумом OMG. В этой архитектуре, которая поддерживается в ряде продуктов семейства IBM/Rational, разработка приложений начинается с создания независимой от специфики реализации модели приложения, на базе которой потом автоматически генерируется модель для конкретной платформы и коды приложения. Высокий уровень абстракции при проектировании приложений в MDA хорошо согласуется с подходами SOA, представляющей приложения как сервисы, взаимодействующие для реализации определенного бизнес-процесса.

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

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

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

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

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

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

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

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

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

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

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

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

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

Литература
  1. K. Channabasavaiah, K. Holley, E.M. Tuggle, Migrating to a service-oriented architecture. IBM, December 2003
  2. Service orientation market trends. ZapThink, December 2003.
  3. Transforming your business to on demand. IBM's approach to service-oriented architecture. IBM, 2004.
  4. Worldwide Web services software 2004-2008 forecast: cautious adoption continues. IDC, April 2004.

Из чего делается SOA

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

  • Обеспечение безопасности

  • Управление идентификацией
  • Управление доступом и политиками
  • XML-шифрование
  • Защита от преднамеренных атак
  • Управление корпоративной политикой информационной безопасности
  • Управление соглашениями об уровне обслуживания

  • Управление

  • Мониторинг Web-служб
  • Анализ корневых причин
  • Управление жизненным циклом Web-сервисов
  • Средства измерения параметров и биллинг для Web-сервисов
  • Динамическая маршрутизация
  • Трансляция протоколов и преобразования синхронной/асинхронной передачи
  • Композиция и инкапсуляция
  • Публикация и обнаружение Web-сервисов
  • Мониторинг бизнес-процессов
  • Управление ресурсами
  • Управление корпоративной политикой информационной безопасности
  • Управление соглашениями об уровне обслуживания

  • Интеграция

  • Динамическая маршрутизация
  • Трансляция протоколов и преобразования синхронной/асинхронной передачи
  • Композиция и инкапсуляция
  • Инфраструктура передачи сообщений
  • Публикация и обнаружение Web-сервисов
  • Управление транзакциями
  • Отображение данных
  • Управление семантической информацией
  • Управление потоком работ
  • Управление бизнес-процессами

  • Поддержка процессов

  • Управление соглашениями об уровне обслуживания
  • Трансляция протоколов и преобразования синхронной/асинхронной передачи
  • Композиция и инкапсуляция
  • Отображение данных
  • Управление семантической информацией
  • Управление потоком работ
  • Управление бизнес-процессами
  • Мониторинг бизнес-процессов
  • Бизнес-моделирование
  • Моделирование сервисов

  • Инструментарий

  • Композиция и инкапсуляция
  • Бизнес-моделирование
  • Моделирование сервисов
  • Средства быстрой разработки
  • Средства тестирования Web-сервисов
  • Сервис-ориентированные средства разработки

SOA в примерах

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

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

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

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

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

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