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

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

Дон Баскард, старший вице-президент и технический директор компании AXA Financial, имеющей оборот 7,5 млн. долл. и работающей в области страхового бизнеса и финансовых услуг, сравнивает свою сервисно-ориентированную архитектуру (SOA) с системой, состоящей из взаимосвязанных механизмов: некоторые из них громоздки и малоподвижны, другие отличаются компактностью и быстротой. Баскард, как и многие другие, считает SOA очень удачным решением для ИТ-среды, где относительно медлительные унаследованные системы обработки данных должны сосуществовать с динамичными клиентскими приложениями. SOA становится своего рода источником энергии, движущей силой, приводящей все в действие.

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

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

Что за «зверь» эта SOA?

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

Всего лишь CORBA в новой одежке?

Архитектура SOA прошла эволюционный путь развития от традиционных приложений с жесткими связями, в том числе от общей архитектуры брокера объектных запросов (common object request broker architecture, CORBA), к слабосвязанным приложениям (таким как Web-сервис). Жесткие связи усложняют адаптацию приложений к изменяющимся потребностям бизнеса, поскольку любая модификация одного приложения влечет за собой необходимость корректировки связанных с ним программ. Кроме того, при объектно-ориентированной разработке используется достаточно мелкий уровень модульности, в качестве объектов могут фигурировать сотрудники или клиентские заказы. В архитектуре SOA сервис определен на более абстрактном уровне, например, бизнес-процесса (в частности, выставление счета на оплату телефонных переговоров).

В чем преимущества SOA?

Архитектура SOA упрощает интеграцию практически любых ИТ-сред, которые можно сегодня встретить в большинстве компаний. «В этом и состоит главная ценность SOA, — полагает Джейсон Блумберг, главный аналитик компании ZapThink, специализирующейся на предоставлении консультационных услуг в области Web-сервисов. — Она очень хорошо работает в неоднородной среде». Разработчики избавлены от необходимости тратить уйму времени на написание новых строк кода, чтобы установить связи между приложениями. Достаточно использовать стандартные протоколы (в частности, Web-сервисов). Крупные блоки кода SOA допускают повторное использование, что уменьшает стоимость разработки. Архитектура SOA берет унаследованные активы и ресурсы (системы SAP, Siebel, Oracle и т. д.), обеспечивает их слаженное (вдобавок более выгодное) совместное функционирование.

«К позитивным особенностям SOA следует отнести возможность использования уже существующего портфеля», — полагает президент консультационной компании Silk Road Тим Басс. Не нужно лезть внутрь и заменять эти системы чем-то новым. Определив возможности существующих систем и используя их по назначению, вы выводите ценность инвестиций в ИТ на максимальный уровень, одновременно минимизируя риски. Построение с использованием, к примеру, упрощенного протокола доступа к объектам (simple object access protocol, SOAP) и языка описания Web-сервисов (Web-services description language, WSDL) не только сглаживает внутренний интеграционный процесс, но и облегчает клиентам и деловым партнерам обмен информацией через межсетевые экраны компании.

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

Этот диалог станет по-настоящему продуктивным, если руководство компании всерьез задумается о более эффективных способах ведения бизнеса. Какие процессы нужно внедрить для максимального удовлетворения потребностей клиентов? Как можно поднять уровень их обслуживания? В частности, публикуя информацию приложений, которые когда-то считались балластом, компании могут получать данные об эффективности ведения дел в режиме реального времени, совершенствуя тем самым интеллектуальную составляющую бизнеса. «Общая архитектура открывает немыслимые ранее возможности, которыми компании с успехом могут воспользоваться, — отмечает старший аналитик Gartner Group Дана Гарднер. — Если на Восточном побережье ураган и требуется срочно перевезти массу фанеры через всю страну, я могу откликнуться на запрос в режиме реального времени. У меня теперь самая актуальная информация о том, что происходит в бизнесе, и кое с чем мне не доводилось сталкиваться ранее». В идеальном мире SOA компании лучше адаптируются к изменениям потребностей бизнеса и рыночных условий.

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

Какую роль в SOA играют Web-службы?

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

А между тем Баскард построил в своей компании архитектуру SOA без каких-либо Web-сервисов, причем никто из внутренних и внешних клиентов ни разу не высказал замечаний по этому поводу (правда, ситуацию необходимо постоянно держать под контролем, потому что соответствующие запросы могут поступить в любую минуту). Для организации взаимодействия и интеграции унаследованных систем с клиентскими приложениями на уровне сообщений используется продукт IBM WebSphere MQ. Он работает в тандеме с пакетом Candle PathWAI, который помогает оптимизировать WebSphere MQ и осуществлять мониторинг его производительности.

Главный инженер подразделения Northrop Grumman Mission Systems в Colorado Springs Engineering Organization Джон Джонсон также построил архитектуру SOA на основе системы публикации и подписки (см. Глоссарий SOA) без использования Web-сервисов. Он установил на Web-сервере ПО Java Message Service, работавшее на уровне сообщений, развернул сервер приложений и использовал корпоративную сервисную шину компании Sonic Software, с помощью которой осуществлялись интеграция и перемещение данных. По словам Джонсона, его механизмы очень похожи на Web-сервисы, но не имеют присущего им интерфейса.

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

Что еще предстоит решить?

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

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

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

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

Существуют ли общепринятые методы построения архитектуры SOA?

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

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

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

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

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

Имеет ли смысл задуматься о переходе на архитектуру SOA?

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

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

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

И тем не менее можно с уверенностью утверждать, что эта стратегия заслуживает внимания.

Todd Datz. What You Need to Know About Service-Oriented Architecture. CIO Magazine. January 15, 2004

Глоссарий SOA

Корпоративная сервисная шина (Enterprise service bus): Программная инфраструктура, в которой для интеграции приложений используется стандартный интерфейс и технология обмена сообщениями — один из способов реализации SOA. (Замечание: относительно новый термин, впервые появился в одном из отчетов Gartner.)

Слабосвязанный (Loosely coupled): Использование для объединения служб четко определенных интерфейсов. Архитектуры SOA строятся на основе идеологии слабых связей, когда внесение изменений в один сервис не требует корректировки связанных с нею сервисов.

Промежуточное ПО, ориентированное на сообщения (Message-oriented middleware, MOM): Программное обеспечение MOM, называемое также архитектурой, ориентированной на сообщения, представляет собой механизм для организации связей между различными приложениями, а иногда и платформами. Данные размещаются в очередях сообщений, а программы-получатели могут извлекать их без формирования прямых соединений с приложениями-отправителями.

Подписка на публикацию (Publish-subscribe): Система, где одни сервисы рассылают (или «публикуют») данные, а другие могут выдавать на них запросы (или «подписываться»). При изменении опубликованной информации сервиса подписки автоматически принимают обновления.

Сервисно-ориентированная архитектура (SOA): Архитектура, создаваемая на основе набора повторно используемых компонентов с четко определенными интерфейсами.