СОА: новое время - новые песни

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

Применение инструментария наподобие Mindreef SOAPscope 4.0 абстрагирует всю сложность Web-сервисов, позволяя тем самым привлекать к описанию сервисных компонентов представителей бизнес-подразделений

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

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

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

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

Чтобы вырваться из замкнутого круга одних и тех же ошибок, нужно осваивать новые стандарты, набираться нового опыта, осваивать новый инструментарий. Но не менее важно четко осознать разницу между частью (то есть компонентной технологией СОА) и целым (архитектурой ИТ, предназначенной для решения конкретных задач и достаточно гибкой, которую можно создать на основе таких частей).

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

Но существует и еще большая опасность: посчитать, будто любая созданная на базе Web-сервисов архитектура ИТ автоматически становится сервисно-ориентированной.

Не всякая ориентация на сервисы - СОА

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

С технической точки зрения СОА обеспечивает интеграцию приложений без установления жестких взаимосвязей между бизнес-процессами. Знания из одной структуры данных здесь не встраиваются в бизнес-логику другого процесса. Наоборот, открытая природа и податливость XML позволяют изолировать требования к данным со стороны отдельных приложений. В системах СОА все необходимые сервисы трансляции XML используют ту же "сервисную шину", что и бизнес-процессы.

Основные элементы современной СОА

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

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

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

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

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

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

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

Достаточно длинный рычаг

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

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

Новые коллективно разработанные производителями стандарты наподобие WS-Security и WS-Policy наконец-то избавили нас от подозрительных пробелов в начальных версиях протоколов Web-сервисов (вспомним хотя бы, сколько раз встречается фраза "данная страница выпущена сознательно" в спецификации того же SOAP).

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

"Если типичное приложение для .Net, где сообщения будут надежно защищаться на всем пути их прохождения, создается без обращения к нашей библиотеке Web Services Enhancement, разработчику придется написать около 60 тыс. строк кода, - говорит архитектор проекта Microsoft Indigo Джон Шевчук. - Разве это дело - отвлекать специалистов от решения насущных проблем и заставлять их заниматься техническими тонкостями? Мы же силами небольшой команды можем упаковать такой код в библиотеку наподобие WSE. Двадцать тысяч строк при этом сжимаются до десятка тысяч".

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

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

Похоже, что проект Indigo не пойдет по пути других технологий Microsoft, постоянно отстающих от заявленных сроков выхода. По словам Шевчука и других инженеров корпорации, этот продукт, как и было обещано, уже в 2006 г. появится в Windows XP и Windows Server 2003, а затем войдет составной частью и в новые платформы.

В условиях, когда сроки выпуска Longhorn отодвигаются все дальше, тестовый центр eWeek Labs видит в Microsoft Indigo весьма привлекательное средство интеграции для построения СОА. Независимого тестирования у нас, правда, эта перспективная разработка не прошла, да и ждать ее появления еще довольно долго, что несколько умеряет наш энтузиазм. Но Indigo тем не менее предстоит стать заметной вехой на пути к сервисно-ориентированным архитектурам.

Ускорение темпов

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

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

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

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

Спортивные аналогии

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

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

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

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

С редактором Питером Коффи можно связаться по адресу: peter_coffee@ziffdavis.com.