Популярность концепции SOA привлекает внимание к ее открытым проблемам — неудовлет?ворительной надежности и защищенности, слабой поддержке унаследованных систем, непроработанности семантики и малому количеству средств для разработки Web-сервисов
Интерес к концепции SOA (service-oriented architecture — архитектура, ориентированная на сервисы) среди ИТ-сообщества продолжает расти. В то же время идея всеобъемлющей интеграции приложений, о которой с восторгом говорят сторонники SOA, при ближайшем рассмотрении вызывает некоторые сомнения. После детального анализа становятся очевидны серьезные недостатки такого подхода в вопросах надежности, безопасности, организации, поддержки унаследованных приложений и семантики.
Питер Андервуд, вице-президент брокерской фирмы Wall Street Access, считает, что его ИТ-службе предстоит серьезно подумать, прежде чем браться за планирование развертывания SOA.
По его словам, SOA ценна сама по себе, поскольку предусматривает поддержку стандартов на Web-сервисов, но между потенциалом Web-сервисов и их реальными нынешними возможностями остается значительный разрыв.
Специалисты готовы использовать Web-сервисы для решения нехитрых задач, таких как передача информации в Web-порталы. Но для сложных, критически важных задач могут потребоваться такие стандарты на Web-сервисы, которые пока только создаются. Так когда же более целесообразным оказывается использование стратегии SOA, а когда — лучше старая добрая интеграция приложений предприятия (enterprise application integration, EAI)? Все зависит от того, что вы пытаетесь делать и каких именно возможностей в Web-сервисах вам не хватает.
Надежность
Наверное, труднее всего обеспечить высоконадежную, асинхронную передачу сообщений, во всяком случае, сделать это быстро. Аяз Кази, генеральный менеджер по вопросам бизнес-интеграции компании Tibco Software, в которой давно и с успехом используют EAI, назвал такую систему передачи сообщений «критически важной для обеспечения интеграции на корпоративном уровне».
Сэм Бунин, вице-президент по маркетингу компании Blue Titan Software, специализирующейся на разработке инфраструктуры Web-сервисов, заметил: «SOA пока не готова обеспечить даже минимальную надежность при обработке транзакций — строгое выполнение обязательств, доставку информации один и только один раз и возврат к предыдущему состоянию. Но пройдет определенное время, и стандарты и реализации будут усовершенствованы до такой степени, что смогут выполнять это требование».
Фактически в некоторых предварительных спецификациях на Web-сервисы уже предлагается решение многих вопросов, связанных с критически важными и продолжительными процессами. Например, спецификация WS-ReliableMessaging призвана гарантировать, что сообщения SOAP обязательно будут переданы по назначению. WS-AtomicTransaction, WS-Eventing и ряд других предварительных спецификаций указывают способы поддержки сложных, длительных бизнес-транзакций, с сохранением стабильного состояния. Однако, в отличие от множества протоколов, связанных с защитой, говорить о широком использовании подобных стандартов обеспечения надежности пока еще рано.
До сих пор, как подчеркнул Крис Кроухорст, вице-президент по корпоративной архитектуре компании Thomson Prometric, «надежная передача сообщений для Web-сервисов довольно обременительна, но все же приложения должны строиться на основе, учитывая преимущества, которые дает интероперабельность Web-сервисов».
Пока под таким «созданием на основе» понимают разработку приложений, способных прогнозировать и устранять условия, которые могут повлечь возникновение ошибки. Это также означает поддержку взаимодействия SOAP по принципу «точка-точка» с посредником вроде брокера управления Web-сервисами, который формирует стандартизованный уровень абстракции. Подобные программные продукты, предлагаемые рядом независимых производителей, в частности Actional, AmberPoint и Blue Titan, позволяют менеджерам восстанавливать работу после сбоя и обновлять программное обеспечение с минимальным вмешательством в производственные системы. (Приемлемая система управления Web-сервисами должна работать на различных платформах, что объясняет отсутствие аналогичных решений у таких ведущих производителей, как BEA Systems, IBM и Microsoft.)
С другой стороны, максимальная надежность, как правило, необходима для асинхронных, продолжительных транзакций с множеством взаимозависимостей, например для сложных финансовых транзакций. Для менее требовательных задач SOAP по HTTP оказывается достаточно надежным средством, особенно в случае простых, синхронных транзакций. Решения, опирающиеся на передачу сообщений, вполне приемлемы для объемных транзакций, выполняемых в пакетном режиме. С другой стороны, Web-сервисы лучше подходят для ситуаций, когда объем невелик, но все должно выполняться в реальном времени.
Безопасность
Предоставление прав доступа, аутентификация и шифрование остаются серьезными препятствиями для ИТ-менеджеров, анализирующих возможности интеграции приложений на базе Web-сервисов. Контроль доступа всегда был трудной задачей, требующей регистрации и аутентификации. В распределенном мире Web-сервисов, где компоненты одного приложения могут легко отключаться и взаимодействовать с компонентами, располагающимися в других доменах, обеспечить защиту разнородных, но связанных друг с другом систем — задача намного более сложная.
Как и в случае надежной передачи сообщений, предлагается множество стандартов на взаимодействия «в стиле» Web-сервисов. Самыми важными и наиболее часто реализуемыми являются WS-Security и SAML. Первый описывает расширяемую платформу для классификации различных аспектов возможностей защиты, в то время как последний определяет стандартный процесс передачи подтверждений для поддержки моделей аутентификации, основанных на механизме «единой точки входа» (Single Sign-On, SSO).
Что касается SOA, то аналитик Фил Вайнрайт на сайте, где обсуждаются вопросы, касающиеся слабосвязанных инфраструктур, выделяет третье, хотя и не разработанное пока столь же глубоко, предложение. Спецификация WS-Policy должна предоставить различным системам средства, позволяющие декларировать, какие виды защитных механизмов они требуют.
«Без этого возможности поддерживать соединения между слабосвязанными доменами будет существенно ограничены», — заметил Вайнрайт.
Хотя ни один из предлагаемых стандартов не способен решить всех проблем защиты Web-сервисов, в совокупности они дают основу для формирования приемлемой стратегии.
Действительно, организация Web Services Interoperability (WS-I) недавно ратифицировала отдельные компоненты WS-Security для своего пакета Basic Security Profile, набора лучших практических решений, призванных гарантировать интероперабельность.
В ближайшее время WS-I планирует добавить поддержку SAML и других стандартов.
Тем не менее пока относительно реальный способ обеспечить защиту Web-сервисов заключается в использовании методик, применяемых для защиты стандартных Web-приложений, прежде всего механизмов транспортного уровня наподобие SSL.
Одним из достоинств SSL является поддержка двунаправленной аутентификации, но существующая сейчас поддержка инфраструктуры сертификатов для большого числа клиентских систем может оказаться крайне сложной. Кроме этого сейчас можно использовать поддерживающие XML многофункциональные межсетевые экраны, предлагаемые, например, компаниями DataPower Technology, Forum Systems, Reactivity и Westbridge Technology, а также цифровые подписи XML, позволяющие принять дополнительные меры по защите сетевого трафика Web-сервисов.
После того как будет создана распределенная архитектура защиты, ИТ-менеджеры смогут вздохнуть чуточку свободнее. Сейчас поддержка защиты приложений зачастую ложится на плечи программистов — далеко не лучший способ использования их потенциала и весьма рискованный с точки зрения организации защиты. При наличии механизмов защиты, основанных на аппарате Web-сервисов, появляется реальная возможность возложить эти обязанности только на соответствующих специалистов.
Такой подход к организации защиты принципиально важен, особенно для компаний, выбравших SOA для своих систем управления заказами и поддержки отношений с заказчиками. Это значит, что компания может реализовать защиту как систему правил, в отличие от ситуации, когда разработчики, по существу, прописывают ее в самом коде приложения.
«Оркестровка»
Координация распределенных программных компонентов с целью выстраивания содержательных бизнес-процессов является, как ни удивительно, самой сложной и наиболее подходящей для ориентированного на сервисы подхода к интеграции. Причина этого очевидна: по существу, приложения, созданные на базе SOA, можно разделять и объединять вновь по мере необходимости. Как основа современных решений управления бизнес-процессами (business process management, BPM), так называемая «оркестровка» позволяет ИТ-менеджерам формировать новые метаприложения из функций коммерческих приложений или приложений, созданных в самой компании.
Бунин заметил, что такая возможность особенно важна для компаний, выбравших стратегию интеграции на основе SOA.
«Они создают объединенные приложения на базе инфраструктуры SOA и «оркестрованных» сервисов в повторно используемых бизнес-процессах», — подчеркнул он. На первый взгляд объединение этих фрагментов для управления потоком бизнес-транзакций не представляет собой ничего сложного. В конце концов, основной камень преткновения для решений категории BPM — это монолитная природа существующего программного обеспечения. Web-сервисы, со своей стороны, разделяют программные системы на компоненты, каждый из которых связан с вполне определенной бизнес-функцией.
Самое сложное — не создать модульные приложения, а изменить способ, каким эти системы представляют обрабатываемые ими данные. Кроухорст рекомендует «определить схему, лежащую в основе бизнеса, а не создавать отдельно для конкретных систем потоки процессов и структуры представления данных». Другими словами, лучше представлять себе результаты бизнес-процессов как документы, которые содержат ответы на все основные вопросы, возникающие в ходе выполнения этих бизнес-процессов. XML, основополагающий элемент Web-сервисов, позволяет успешно реализовать эту концепцию.
Предложено несколько стандартов оркестровки и BPM. Один из них, BPEL (Business Process Execution Language), получил широкую поддержку в отрасли и даже реализован в нескольких продуктах BPM, хотя все признают, что зрелая его версия, BPEL 2.0, будет закончена не раньше чем через полтора года. Дополняющие BPEL спецификации, WS-AtomicTransaction и WS-CAF (Composite Application Framework), предназначены для поддержки сложных транзакций, из которых состоят продолжительные и сохраняющие состояние бизнес-процессы.
Фирмы, специализирующиеся на BPM, компании, использующие EAI, и ведущие производители платформ считают весьма перспективной возможность визуализировать, выполнять и контролировать процессы с помощью этой новой, основанной на стандартах формы BPM. Ее поддерживают и производители корпоративных бизнес-приложений, такие как SAP и Oracle (последняя приобрела в этом году компанию Collaxa, разработчика систем BPM). SAP выбрала радикальный подход, по существу перепроектировав свое программное обеспечение таким образом, чтобы интегрировать собственную версию программного обеспечения промежуточного слоя, предназначенного для управления и интеграции бизнес-процессов и получившего название NetWeaver. Наконец, хранилища данных, поддерживающие XML и специально созданные в расчете на SOA, такие как Data Director компании Blue Titan и Tamino компании Software AG, становятся все более важным аспектом в реализации схемы бизнес-процессов.
Поддержка унаследованных систем
Программные решения, используемые для связи приложений с унаследованными системами, играют роль переходника, который позволяет американцу, приехавшему в Европу, подключать ноутбук к обычной электророзетке, то есть представляют собой специализированный адаптер для приложений, позволяющий одной системе получать данные из другой.
И точно так же, как практически в каждой стране имеется свой собственный стандарт на розетки, каждая унаследованная система требует своего адаптера. Многие годы производители EAI рассматривали диапазон предлагаемых ими адаптеров для унаследованных приложений как свое основное отличие от конкурентов и как дополнительный источник дохода.
К счастью, по мере появления различных стандартов, в частности и на Web-сервисы, все больше внимания уделяли решению вопроса интероперабельности, и расходы на создание простых соединений стали сокращаться. А компании, специализирующиеся на создании адаптеров для приложений, такие как Attunity и iWay, значительно расширили спектр возможностей поддержки связи.
Одно из преимуществ адаптеров для унаследованных приложений, о котором часто забывают, заключается в том, что они скрывают сложность и «ограниченность» многих внутренних API. Роль хорошего адаптера не столь уж отличается от роли хорошо организованной Web-сервисы. Адаптер формирует уровень абстракции, который изолирует остальную инфраструктуру приложения от всякого рода сбоев и ошибок. Некоторые производители, такие как Software AG, специализируются на «семантической интеграции» унаследованных приложений с основными компонентами интеграции на базе XML.
Пакетные приложения таких компаний, как Oracle и SAP, уже предлагают определенную поддержку связи на базе стандартов, как правило, за счет создания оболочки вокруг внутренних API, таких как SAP Business API, с интерфейсом SOAP. По мере того как производители приложений начинают использовать Web-сервисы и добавляют к своим продуктам функции, присущие программному обеспечению промежуточного слоя, стандартный метод интеграции пакетных приложений будет отражать наилучшие практические решения SOA.
Но даже в этом случае использование дорогостоящих внутренних адаптеров приложений по-прежнему будет единственной возможностью для связи многих действительно архаичных систем с общей платформой интеграции.
У предприятий, использующих мэйнфреймы и придерживающихся политики переноса основных наборов Web-служб на свое «антикварное» оборудование, есть лишь одна надежда. По иронии судьбы свойственные для мэйнфреймов жесткие API окажется легче интерпретировать для SOAP, нежели «хаотичные» интерфейсы, реализованные в многочисленных клиент-серверных системах.
Семантика
Определение смысла транзакций и данных с точки зрения бизнеса — одна из самых сложных и труднорешаемых задач, с которыми сталкиваются ИТ-менеджеры. Хотя трудности семантики существовали еще до появления Web-сервисов (например, вертикальные отрасли вот уже многие годы разрабатывают свои собственные XML-схемы), SOA выводят семантику на передний план. Фактически взаимодействие на смысловом уровне — основа хорошо спроектированных SOA.
Не существует ни одной технологии или программного продукта, способного действительно решить проблему семантики. Бизнес-менеджеры и специалисты по информационным технологиям вынуждены брать на себя тяжелую работу по определению и реализации функций и моделей данных для отрасли, а также специализированных процессов. Тем не менее решение многих из этих задач могут упростить предварительно созданные компоненты и помощь опытных консультантов.
Производители EAI считают, что их более обширный опыт в создании решений интеграции способен оградить их от тенденции превращения «всего и вся» в предметы широкого потребления, которую порождают стандарты на Web-сервисы.
При переходе на поддержку SOA производители пакетных приложений также считают свой опыт работы с конкретными отраслями и бизнес-процессами своим активом. В частности, SAP особое значение придает своей инициативе xApps, в рамках которой создается реализация на базе Web-сервисов таких бизнес-процессов, которые «пронизывают» вертикальные системы.
Все больше и больше компании осознают важность стандартов на основе XML для своих отраслей. Например, отрасль финансовых служб разработала FIXML (Financial Information Exchange Markup Language), протокол обмена для банковских транзакций, а бухгалтерская отрасль предлагает XBRL (Extensible Business Reporting Language) для описания и аудита главной бухгалтерской книги. Производители, работающие в сфере высоких технологий, продолжают использовать «прародителя» словарей XML, RosettaNet, для обмена информацией о продуктах и компонентах продуктов в своих цепочках поставки.
Фактически многие аналитики считают, что динамика той отрасли, в которой работает компания, может стать одним из важных стимулов, определяющих, когда и как эта компания перейдет на SOA. Боб Сатор, директор IBM по инфраструктуре WebSphere, заметил, что особенно активно идеи SOA проникают в финансовые службы. Помимо технологических катализаторов, таких как стандарты вертикальной отрасли, по его словам, не менее важной причиной в этом случае является большое число слияний и приобретений. Вместо того чтобы медленно отсортировывать и тиражировать информацию из системы одной компании в систему другой, разумные руководители должны использовать решения в стиле SOA для того, чтобы, по его словам, «активно интегрировать бизнес-подразделения в одну сеть» быстро и без потерь, которые неизбежны в противном случае.
Несмотря на все эти трудности, большинство ИТ-менеджеров согласны с тем, что внедрение инфраструктуры интеграции, ориентированной на сервисы, — это в большей степени вопрос «когда», нежели «нужно ли».
Но даже в этом случае старая поговорка «семь раз отмерь — один отрежь» весьма актуальна. Без четкого бизнес-анализа и принципов, управляющих разработкой, как заметил Андервуд, «вы в итоге воссоздадите интерфейсы, которые окажутся сущим кошмаром».
Дэвид Спротт, генеральный директор и ведущий аналитик исследовательской компании CBDi, согласен с такой точкой зрения, но предупреждает, что переход на стратегию, поддерживающую сервисы, не должен быть совершен исключительно по соображениям технологии.
«Переход на мышление в терминах сервисов поможет специалистам по бизнесу и по ИТ говорить на одном языке. Однако не следует использовать сервисы только потому, что сейчас это модно. Это решение должно приниматься исходя из требований бизнеса и с учетом отдачи от инвестиций», — уверен Спротт.
Кроухорст также считает, что крайне важно понять, как представить основные бизнес-процессы в виде сервисов.
«Это требует определенных изменений в сложившейся культуре разработки, — заметил он. — По сравнению с этим технические сложности — не более чем умственные упражнения».
Брент Слипер — руководитель компании Stencil Group, предоставляющей консалтинговые услуги по вопросам бизнеса
Пробелы в SOA - чем их заполнить
Наличие недостающих фрагментов в сервисно-ориентированной архитектуре SOA диктует необходимость в зрелых стандартах на Web-сервисы, многие из которые сейчас весьма далеки от такого состояния. Однако эти пробелы могут пока заполнить традиционные технологии (см.таблицу)
Как насчет производительности?
Критики Web-сервисов и SOA часто утверждают, что основное препятствие к их широкому распространению — это недостаточная производительность. Стандартизация всегда требует определенных уступок в скорости.
Пять проблем, перечисленных в статье, отражают компромиссы, определяемые распределенной, слабосвязанной природой SOA, опирающейся на Web-сервисы. Но скептики часто называют именно производительность явным недостатком этой модели. Критика в общем касается двух моментов: распределенной природы SOA и накладных расходов протоколов Web-сервисов.
Любая распределенная система работает медленнее, чем замкнутая, просто потому, что сеть становится ограничивающим фактором. И, конечно, для некоторых приложений просто недопустимы задержки, возникающие в сети. Но эта аксиома верна не только для Web-сервисов или SOA. Преимущества в гибкости и доступе, получаемые за счет сохранения связи системы с модулями, работу которых они представляют (и связи этих систем с другими по всей организации или по Internet), безусловно, оправдывают снижение производительности, возникающее за счет использования сети.
Более разумное возражение — относительный «вес» XML-транзакций по сравнению с двоичными. По некоторым оценкам, серверу Java-приложений для того, чтобы преобразовать в последовательную форму и обратно вызовы SOAP к внутренним объектам, потребуется «приложить» в десять раз больше «усилий», чем требуется для оригинальных подходов, таких как Remote Method Invocation. Это звучит убедительно до тех пор, пока вы не вспомните уроки, полученные от работы в самой Web. Как и HTML, XML — очень «многословный» подход к описанию информации. Однако он настолько понятный и расширяемый, что это компенсирует снижение производительности, причем, как обещает Закон Мура, с появлением специализированных устройств, таких как ускорители XML, со временем говорить о потерях производительности не придется вовсе.
В итоге ни сторонников Web-сервисов, ни их критиков нельзя считать единственно правыми. Это все вопрос использования верного инструмента для выполнения верной работы. Транзакции большого объема по-прежнему еще какое-то время будут обслуживаться с помощью внутренних, бинарных программных решений промежуточного уровня. Но для приложений, которые требуют менее частых, но более гибких взаимодействий, все чаще и чаще будут применяться Web-сервисы.