«Открытые системы» , № 06, 2004 797 прочтений

SOA: подходы к реализации

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

Наталья Дубова

Появление концепции сервисно-ориентированной архитектуры (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 — это компонентная модель, в которой разные функциональные единицы приложений, называемые сервисами, взаимодействуют по сети посредством интерфейсов. Расшифруем данные определения.

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

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

Литература

K. Channabasavaiah, K. Holley, E.M. Tuggle, Migrating to a service-oriented architecture. IBM, December 2003
Service orientation market trends. ZapThink, December 2003.
Transforming your business to on demand. IBM's approach to service-oriented architecture. IBM, 2004.
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 — задача не разработчиков, а архитекторов программных систем. В компетенции разработчиков остается создание функциональных модулей, которые будут определены в качестве сервисов, но задачи сопряжения этих сервисов в единое целое для реализации бизнес-процесса должны решаться на уровне моделирования.

Страница 1 2 3

получить код для вставки в блог