Computerworld, США

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

В этом смысле сервис-ориентированные архитектуры (Service-Oriented Architecture, SOA) и Web-сервисы не исключение. Они создаются исходя из понимания того, Web — самое масштабируемое и гибкое распределенное приложение из когда-либо существовавших. Мы можем повторно использовать то, что уже доказало свою полезность, — слабое связывание, прозрачные протоколы, серверную инфраструктуру — в более широком мире сетевых решений, ориентированных на приложения. Более тщательный анализ позволяет обнаружить аналогии в развитии Web-инфраструктуры.

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

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

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

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

Производительность SOA по-прежнему будет снижаться, когда появится новый стандарт, еще больше усложняющий и без того загадочный механизм обработки сообщений. Модель расширяемых заголовков сообщений, которая определяет Simple Object Access Protocol (SOAP), превосходна, но, возможно, именно в этом кроется причина ее неудачи — стандарты на обработку сообщений становятся все более запутанными, а вовсе не более единообразными и простыми.

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

Производителей серверов приложений такая ситуация только радует. Чрезмерно раздутый стек SOAP с новыми возможностями и стандартами может привести к постепенному снижению производительности, но это означает, что пользователи будут покупать больше оборудования и лицензий на серверы приложений.

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

И найти ответы на эти вопросы можно, обратившись к истории. Когда дополнительная нагрузка на вычислительные ресурсы, связанная с шифрованием, стала негативно сказываться на производительности Web, ее перенесли на специальные аппаратные ускорители уровня Secure Sockets Layer (SSL). Когда потребности приложений начали превышать ресурсы одного сервера, эти приложения перенесли на кластеры, в которых специальные аппаратные устройства выполняют балансировку нагрузки, корректно распределяя ресурсы. Когда аутентификация и авторизация стали слишком дорогими для того, чтобы их можно было выполнять локально на сервере приложений, вся эта деятельность была перенесена на специальные серверы-посредники.

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

Нет ли чего-то подходящего для XML-обработки в SOA и Web-сервисах? Конечно, есть. Но сейчас некоторые из этих базовых функций объединены в один модуль. Увеличение производительности XML-обработки может быть достигнуто, например, в XML Gateway, который не только выполняет аутентификацию и авторизацию при доступе к сервисам (о чем говорит его название), но и ускоряет операции шифрования (для защиты на базе SSL и Oasis Web Services Security), преобразования сообщений с помощью регулярных выражений и XSLT и даже маршрутизацию и балансировку нагрузки между провайдерами сервисов. Все это должно быть сделано с помощью специализированного аппаратного обеспечения для XML-обработки.

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

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