В последнее время крупные производители ПО много усилий тратят на продвижение двух технологий - Web-сервисов и сервисориентированных архитектур (СОА). Но, глядя на эти разработки со стороны, часто кажется, что они создают не меньше проблем, чем решают. В конце ноября в рамках IBM e-Business Forum я испытал несколько своих мыслей по этому поводу в беседе с Марком Коланом - главным человеком, ответственным в IBM за популяризацию ее позиции в вопросах, связанных с технологиями электронного бизнеса (дословно его пост звучит как Senior e-Business Evangelist at IBM). Вопреки моим опасениям, его ответы оказались не очень пропагандистскими, а сама беседа заслуживает того, чтобы воспроизвести основные ее положения.

От бумажного мира к реальному

В мире Web-сервисов - десятки потенциальных стандартов, охватывающих самые разные области. Но часто кажется, что работа здесь по большей части идет на бумаге: спецификаций много*1, а поддерживается в продуктах только несколько основных - SOAP, UDDI, WSDL. Среди тех технологий, поддержка которых пока отсутствует, есть и такие важные, как WS-Transaction или аналогичные спецификации от группы во главе с Sun Microsystems и Oracle. Нет также реализованных версий ряда других стандартов безопасности - WS-Policy, WS-Trust, WS-SecureConversation. Все это, на мой взгляд, заставляет скептически оценивать кипучую деятельность авторов данных спецификаций.

_____

*1 Всего на рынке их более 40, и по меньшей мере 20 - часть архитектуры GXA (Global Web services Architecture), продвигаемой IBM и Microsoft. Подробнее они рассмотрены в обзоре Web-сервисы в корпоративной среде, PC Week/RE, N 27-35/2004.

Однако, по мнению Марка Колана, на ситуацию можно посмотреть и под другим углом. "Нужно понимать, как происходит работа над стандартами, - считает он. - Мы разрабатываем их совместно с Microsoft и другими компаниями. Вначале мы выпускаем спецификации, но редко сразу же начинаем их реализовывать в продуктах. Мы даем возможность им устояться и получить отзывы клиентов, чтобы убедиться в правильности заложенных в них подходов".

В качестве примера он приводит BPEL (Business Process Execution Language - язык исполнения бизнес-процессов), который был впервые опубликован в августе 2003-го и в мае 2004 г. обновлен до версии 1.1. Весной 2004-го спецификация была реализована в продукте IBM WebSphere Business Integration Server Foundation 5.1 (WBISF). Тогда же был запущен процесс стандартизации BPEL.

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

По словам главного евангелиста IBM, корпорация много вложила в создание разных спецификаций Web-сервисов и возглавляет ряд комитетов по их стандартизации, что, конечно, хорошо известно. Но помимо этого она много внимания уделяет реализации данных документов в своих программных продуктах. Скажем, WSDL, SOAP, UDDI поддерживаются в продуктах IBM достаточно давно - впервые реализация SOAP появилась в WebSphere Application Server (WAS) в 2001 г., а еще ранее - в экспериментальных релизах. С тех пор вышло четыре главных релиза, и с каждой версией реализация SOAP становится более совершенной.

"В версии 5.1 (в марте должна выйти версия 6.0) скорость работы Web-сервисов приближается к скорости RMI-over-IIOP (это технология удаленного вызова методов Java. - В. Б.). Когда производительность столь высока, а стандарты поддерживаются разными вендорами (что обеспечивает высокую интероперабельность), Web-сервисы становятся очень привлекательными, - полагает мистер Колан. - В наших продуктах реализовано и поддерживается много других спецификаций. В частности, механизм безопасности на основе черновых вариантов спецификации WS-Security включается уже в третий релиз WAS подряд, а в версии WS AS 6.0 появится реализация окончательной версии стандарта WS-Security 1.0".

Поддержка Web-сервисных технологий встраивается не только в платформу, но и в средства разработки. Так, для применения WS-Security в приложениях не нужно писать никакого кода - ее поддержка включается просто настройкой в дескрипторе развертывания параметра, указывающего, какую среду безопасности использовать. После этого инструмент разработки самостоятельно сконфигурирует среду исполнения для вызова нужного менеджера безопасности (Security handler). В целях достижения совместимости ПО корпорация IBM сотрудничает с Microsoft, среда .Net которой также поддерживает WS-Security.

Что касается других протоколов безопасности, например WS-SecureConversation, WS-Policy, WS-Trust, WS-Federation и др., то некоторые из них будут включены в обновленную модель безопасности сервера приложений IBM. Эту модель, правда, предполагается реализовать только в одном из обновлений WAS 6.0, планируемых к выпуску в течение следующего года или позже.

В качестве еще одного примера уже реализованного стандарта, отличного от базовой тройки SOAP - WSDL - UDDI, евангелист э-бизнеса называет уже упомянутый BPEL. Среда Rational Application Developer (бывшая WebSphere Studio) и средство моделирования WebSphere Business Integration Modeler позволяют бизнес-аналитикам создавать графические описания процессов и генерировать BPEL-код, а также UML-диаграммы. Подготовленные таким образом BPEL-сценарии затем можно развернуть на сервере WBISF, представляющем собой версию сервера приложений WAS, оснащенную встроенным механизмом исполнения BPEL. На этапе развертывания к ключевым точкам (интерфейсам) процесса подключаются внешние Web-сервисы.

И наконец, новым важным стандартом, реализация которого появится в WAS 6.0, будет WS-AtomicTransaction ("потомок" одного из разделов WS-Transaction). "Наши клиенты и аналитики отрасли хотят получить транзакционный стандарт. В списке их требований данное стоит на втором месте, после требования безопасности", - объясняет ситуацию Колан. В WAS 6.0 будет поддерживаться черновой вариант WS-AT.

И все же многие подобные вещи являются, по мнению Колана, скорее удобным дополнением, чем насущной необходимостью: "Компаниям не обязательно ждать, пока все будет готово. Они могут извлекать из WS выгоду уже сейчас: в качестве промежуточного решения вместо вспомогательных стандартов можно использовать другие технологии. Много хороших приложений можно создать просто при помощи SOAP, WSDL, WS-Security. Более того, основная масса приложений будет использовать только этот базовый слой".

Эволюция стандартов: путь к новой несовместимости?

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

По словам Марка Колана, подход корпорации к интероперабельности сервисов базируется не на фиксации номеров конкретных спецификаций, а на фиксации профилей WS-I. Напомним, что это - наборы документов, которые устраняют разночтения разных спецификаций и объясняют, какие из спецификаций должны быть реализованы в продуктах для обеспечения совместимости между ПО всевозможных вендоров.

WS-I Basic Profile 1.0 был опубликован летом 2003-го. Он реализован в WebSpere 5.1 SP2. Сейчас утверждена версия BP 1.1, в ней пересмотрена модель безопасности. Идет работа над профилем, включающим SOAP 1.2 - новейшую версию этого стандарта. Кроме того, разрабатывается Security Profile 1.0, который будет готов в ближайшем будущем. Цель разработки любой спецификации - сделать их частью подобного базового профиля.

"Я думаю, что в будущем IBM и другие вендоры обеспечат поддержку одновременно нескольких версий основных стандартов. Скорее всего будет поддерживаться более чем одна версия базового профиля", - говорит Колан.

Сервисориентированная диктатура

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

По мнению г-на Колана, Web-сервисы и SOA приведут к изменению культуры ИТ-организаций. BPEL увеличит власть бизнес-аналитиков: они получают больший контроль над разработкой и внедрением бизнес-процессов. СОА устраняет недостатки объектно-ориентированного подхода (ООП), который не оправдал надежд многих компаний на многократное использование кода (особенно в программах, написанных на разных языках) и простоту создания распределенных приложений. СОА позволяет создавать распределенные объекты, которые можно дистанционно вызывать с других компьютеров, преодолевая к тому же языковый барьер.

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

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

Что касается ведения репозиториев, то это - не обязательный элемент. "Не нужно делать все, что требует методология СОА, - заключает Колан. - Например, если просто используется SOAP для обмена сообщениями и WSDL для описания интерфейсов, то этого, с моей точки зрения, достаточно, чтобы назвать построенную (в проекте) архитектуру СОА. А репозитории - не первое, что делают компании, когда создают Web-сервисы. Для одного сервиса не нужен репозиторий. Нужда в них возникает, когда требуется решать задачи определенного типа, а именно, когда Web-сервисов столько, что трудно понять, что делает каждый из них. Скажем, репозиторий поможет многонациональной компании, имеющей несколько центров разработки, между которыми не налажено достаточно хорошего взаимодействия. Репозиторий также можно использовать для внешних связей, таких, как каталог интерфейсов для партнеров... В реальности вы просто используете возможности СОА, когда нужно сберечь деньги и время, и не заботитесь о том, как этот подход называется".