Успехи и проблемы Web-сервисов

КРУГЛЫЙ СТОЛ EWEEK LABS

Специалисты по Web-сервисам говорят об их перспективах и об опасностях перехода к фирменным решениям

Ведущий: Питер Коффи (eWeek Labs)

Участники:

В стандартах, моделях использования и базовых технологиях Web-сервисов виден заметный прогресс. Мы публикуем сокращенные материалы круглого стола поставщиков технологий и консультантов, организованного eWeek Labs в декабре прошлого года и посвященного перспективам корпоративного применения Web-сервисов.

eWeek: На каком этапе своего пути находятся Web-сервисы?

Либоу: Их рынок уже вышел на широкую дорогу. Множество компаний самых разных отраслей внедряет эту технологию и получает крупную экономию на операционных затратах.

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

eWeek: Соразмерен ли энтузиазм по отношению к Web-стандартам с реальными возможностями технологии?

Эриксон: Это адекватная технология для построения сервисно-ориентированной архитектуры (Service Oriented Architecture, SOA). В то же время она требует определенного переоснащения. В перспективе появятся новые инструменты для поддержки сервисно-ориентированного цикла разработок, обеспечивающего свободные связи систем и неразрывную интеграцию. А некоторые из традиционных инструментов, возможно, выйдут из обихода.

eWeek: Насколько технология сервисов готова изменить корпоративный ИТ-ландшафт?

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

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

Хорошим примером этого подхода в области связывания данных является JSR (Java Specification Request) 227. Предложение, поданное в начале года Oracle, по существу, описывает абстрактный интерфейс для привязки данных к любому бизнес-сервису. Это может быть и Web-сервис, и Enterprise JavaBean, и Java-класс, и вообще все, что вам понравится.

eWeek: Значит, вопрос в том, чтобы корпоративное приложение с определенными потребностями в данных было больше изолировано от конкретной технологии, используемой для хранения и обеспечения доступа к этим данным?

Фаррелл: Совершенно верно. Сейчас в этом аспекте явно превалируют Web-сервисы, однако построение многократно используемых сервисов, которые будут функционировать в сложных n-уровневых средах или grid-среде, в конечном счете принесет огромную отдачу. У пользователей появятся замечательные возможности контроля.

eWeek: Господин Кей, насколько я знаю, в фокусе вашей работы в RDS Strategies находится проверка реального наличия и взаимного соответствия различных элементов всей этой мозаики. Каково ваше мнение о том, что мы уже слышали?

Кей: На сегодняшней встрече, похоже, только я один не из лагеря производителей, и поэтому позвольте мне высказать противоположную точку зрения: я считаю, что с Web-сервисами мы еще находимся в самом начале пути. Большинство существующих реализаций в ретроспективном плане следует отнести к категории тривиальных - это решения на основе RPC (удаленный вызов процедур). Если же говорить о решениях, действительно основанных на стандартах и использующих компоненты разных производителей, то здесь еще многого не хватает.

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

eWeek: Вы имеете в виду, что тут потребуются технологии, которые не причисляются к архипелагу Web-сервисов?

Кей: Здесь еще не проведена стандартизация. Технологии практически для всех Web-сервисов существуют, но все навалено в кучу. Необходимо договориться, что и как мы хотим использовать. Oracle, IBM, Microsoft и другие компании спешат создавать свои решения, но они не обязательно будут совместимы.

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

eWeek: Вопрос к ван Хайзену. Похоже, Sonic видит свою роль в построении платформы с довольно высоким уровнем абстракции, в которой стандарты определяются работающими технологиями. Правильно я думаю?

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

Вместе с тем модель SOA реально предлагает (или может предложить) систематический архитектурный подход к постепенному объединению приложений. Именно в этом состоит ее фундаментальная роль.

Либоу: Я бы не сказал, что мне нравится все услышанное. Тут прозвучало слово "тривиальные". А я приведу противоположный пример: это Visa International Service Association и ее несложное Web-сервисное решение для такого аспекта ее бизнеса, как разрешение споров.

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

eWeek: Благодаря чему Web-сервисы смогли обеспечить эту экономию и возможность быстрой реакции?

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

eWeek: Ну а вы, госпожа Уайсс? Наверное, мне не надо вас спрашивать о позиции Sun Microsystems в отношении того, какую роль играют стандарты в создании более конкурентоспособных решений?

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

eWeek: Нельзя ли привести примеры того, что особенно беспокоит пользователей?

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

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

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

eWeek: И какие стандарты вы имеете в виду?

Блум: В частности WS-ReliableMessaging и WS-Addressing, а также управление контентом при помощи UDDI (Universal Description, Discovery and Integration). Контент, управляемый реестрами, становится все полезнее. И то, что мы видим сегодня, можно отнести к категории подходов, ориентированных на привлечение ПО-посредников, которых часто называют ESB (Enterprise Services bus - шина корпоративных сервисов).

Если взглянуть на предлагаемые решения и их разнообразные компоненты, то можно найти примеры хорошего использования стандартов. Однако применение ряда их составляющих будет возможно только благодаря WS-Addressing. Это, например, реестр для управления компонентами ESB или средства, позволяющие обращаться к компонентам на более высоком уровне абстракции, нежели уровень транспорта. Вполне вероятно, что следующее поколение посреднических решений будет ближе к чистым Web-сервисам или, если можно так сказать, к чисто Web-сервисной ESB.

eWeek: Вы упомянули "шину корпоративных сервисов", и я хотел бы немного об этом поговорить. Одним из главных вопросов, обсуждавшихся, насколько я помню, в 1988 г. в связи с идеей "рынка объектов", была перспектива заменить сборку приложения и его продажу в виде пакета на возможность покупать объекты из различных источников и собирать их динамически. Сегодня мы говорим о пользовании сервисами, доступными через Интернет. Неужели в 2004-м люди смогут находить и задействовать сервисы, исходно не предназначавшиеся для работы друг с другом?

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

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

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

eWeek: Теперь хочу спросить Эриксона. Вы разговаривали с разработчиками о том, что им необходимо знать для реализации сервисов как части дизайна поставляемых вами средств. Готовы ли они за это взяться?

Эриксон: Подготовка к интеграции специализированных Web-сервисов, по-моему, представляет немалую часть в задачах SOA. Одним из важных достижений является спецификация взаимодействия сервисов WS-I Basic Profile и создаваемые под нее инструменты тестирования. Средства тестирования необходимы не только производителям, улучшающим возможности взаимодействия своих платформ, но и конечному пользователю, который занимается развертыванием концевой точки своих Web-сервисов.

Ван Хайзен: В разработке Web-сервисов кроется потенциальный риск того, что в корпоративной среде может появиться масса интерфейсов, практически не способных к взаимодействию. Даже если вы сумеете быстро разработать интерфейс на базе SOAP (Simple Object Access Protocol) поверх HTTP, это вовсе не означает, что ваши проблемы будут решены. Необходима архитектурная дисциплина, способная привить идеи "интероперабельных" интерфейсов.

eWeek: Ну и последний вопрос к Кею. Не считаете ли вы, что мы страдаем от избытка возможных решений?

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

"Мы видим, что пользователи внедряют эту технологию и получают крупную экономию на операционных затратах".