Подводные камни Web-служб

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

Основное назначение Web-служб — обеспечение совместного доступа к распределенным компонентам. Этого можно достичь и простым выполнением вызова процедуры на удаленной машине; особенность технологии Web-служб состоит в том, что она предполагает интеграцию путем обмена XML-сообщениями при помощи протокола SOAP. При этом интерфейсы определяются с помощью языка WSDL (Web Services Description Language), а UDDI (Universal Description, Discovery and Integration) предоставляет службу динамического каталога для компонентов, предоставляющих свои услуги, и для компонентов, которые эти услуги используют.

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

Межсистемное взаимодействие

Web-службы базируются на стандартах XML, SOAP и HTTP. Укажем как они совместно позволяют осуществлять межсистемное взаимодействие.

XML

XML проектировался в основном для того, чтобы снабдить разработчиков инструментарием, упрощающим создание специализированных форматов описания данных, что было весьма актуально, учитывая рост объемов и сложности данных. Все чаще стали возникать задачи, в которых программистам требовалось представлять данные в хорошо структурированной форме. Часто возникали задачи экспорта данных в некоем формате, который можно было бы в перспективе сравнительно легко понимать и обрабатывать. Язык XML, позволив это, предоставил возможность проверки структуры данных, снизив риск обмена поврежденными или неправильно структурированными данными. Это достигается путем задания корректной структуры XML-документа в виде определения Data Description Definition (DTD). Однако DTD не решает проблемы типизации данных; например, можно определить необходимость наличия того или иного элемента в XML-документе, но нельзя задать его тип и граничные значения. Эти ограничения снимает язык XML Schema, позволяющий задавать корректную структуру XML-документа, учитывая при этом типы и допустимые значения элементов.

SOAP

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

Рис. 1. Структура сообщения SOAP

Типичное сообщение SOAP состоит из SOAP Envelop — «контейнера», содержащего сообщения целиком или их обертки. Необязательный элемент — «заголовок» SOAP Header — может содержать метаинформацию, специфичную для сообщения. Элемент SOAP Body («тело») содержит полезную нагрузку сообщения. Заголовок и тело сообщения могут быть структурированы в блоки. Например, тело может содержать два блока, каждый из которых описывает отдельный вызов удаленной процедуры RPC. Рассмотрим пример сообщений пересылаемых в процессе запроса и ответа; клиент запрашивает у сервера цену на продукт по заданному идентификатору:

Здесь происходит вызов удаленного метода с именем GetProductPrice, которому в качестве параметра передается productId, а в ответ возвращается цена продукта Price.

HTTP

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

Проблемы межсистемного взаимодействия

XML

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

Рис. 2. Схема простого взаимодействия с применением XML

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

1. В памяти строится модель XML-документа.
2. Внутреннее представление преобразуется из объектного представления в памяти в текстовый формат, пригодный для передачи по сети. Этот процесс (сериализация) -довольно дорогая процедура, создающая в памяти большое количество объектов.

Обратный процесс преобразования XML-документа во внутреннее представление протекает следующим образом.

1. Выполняется разбор XML-документа - чтение потока символов (текста) и преобразование его в древовидную или иную структуру в памяти.
2. Проводится структурная проверка сообщения на предмет соблюдения форматов передаваемых данных, описанных посредством DTD или XML Schema. Этот шаг может быть опущен.
3. Строится внутренняя модель документа в некой унифицированной форме, например, в виде объектной модели Document Object Model. Этот шаг также может быть опущен.
4. Данные из XML-модели преобразуются во внутреннюю структуру объектов, специфичную для каждого приложения.

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

Справедливости ради, стоит отметить, что в последнее время этой проблеме стали уделять больше внимания. Разработаны указания и методики повышения быстродействия. В первую очередь это касается структурной проверки документа — ее вклад в накладные расходы достаточно серьезен и может составлять до 20% [1], поэтому в ряде случаев стоит вообще задуматься об отказе от проверки, по крайней мере, после разработки и тестирования. Но на такой шаг стоит идти только в случае четко специфицированных интерфейсов и полной ответственности взаимодействующих компонентов за данные, которыми они обмениваются. Такое возможно, как правило, только при внутрисистемном взаимодействии компонентов, а так как для этого существует ряд более простых и быстродействующих API-интерфейсов, например, CORBA или Sun RPC, то стоит задуматься о применимости XML-RPC. Отказ же от проверки при межсистемном взаимодействии крайне нежелателен, ввиду возможных несогласований данных и их форматов.

Другой рекомендацией является тщательный выбор программы синтаксического разбора. Так, в [1] приведено сравнение программ Xerces и Crimson, которое показывает, что второй примерно вдвое быстрее первого.

Еще одной важной рекомендацией является выбор API-интерфейса для обработки XML: SAX (Simple API for XML) [2]; спецификация DOM, разработанная консорциумом W3C; JDOM, специально оптимизированная для использования в среде Java объектная модель документа [3]. Далеко не всегда необходимо строить модель всего документа в памяти (так поступает, например, DOM), достаточно обработать лишь его часть. В этом случае целесообразно использовать API-интерфейс более низкого уровня (скажем, SAX), чтобы избежать разбора и построения в памяти всего документа целиком.

Проблемы интеграции

Иногда противопоставляют Web-службы «закрытым» технологиям DCOM, CORBA [4]. Но и CORBA является открытым стандартом, так что это противопоставление не верно. Среди достоинств Web-служб отмечают отсутствие необходимости в сложной инфраструктуре, которая требуется, например, для CORBA. Это способно облегчить задачи интеграции слабосвязанных систем, которые обмениваются, вообще говоря, небольшими объемами данных и не столь интенсивно, чтобы накладные расходы сильно влияли на производительность. Таким образом, сразу стоит ограничить область применения Web-служб только слабосвязанными системами, обменивающимися информацией, не критичной к задержкам. Поставщиками подобных услуг могут выступать различные системы бронирования и продажи услуг, а также системы, торгующие легко идентифицируемым товаром. Кроме того, товаром такого рода может являться и подписка на информационные услуги, например, на ежедневные аналитические отчеты. Потребителями могут выступать информационные порталы или системы, торгующие сопутствующими товарами. В этих случаях трафик не слишком велик, а информация не носит критического характера.

Однако наиболее принципиальной является проблема согласования семантики данных в различных системах. Если абстрагирование от API-интерфейса является чисто технической задачей, то уход от конкретной семантики сильно затруднен как различием в типах данных (например, в форматах представления чисел с плавающей запятой или денежных единиц), так и их значением. Например, имя заказчика в одной системе может быть представлено в виде сочетания двух полей first-name и last-name, в то время как в другой — подобного разделения по полям нет, а имя и фамилия представлены в виде одного поля name. Возникает необходимость в преобразовании двух полей в одно или, что еще сложнее, наоборот. Некоторые авторы настаивают на построении сложных структур метаданных, нацеленных на решение подобных проблем [5]. Однако появление еще одного промежуточного звена только усложняет интеграцию.

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

HTTP как транспорт для SOAP

Использование HTTP как транспорта для SOAP обладает рядом преимуществ. Среди них — независимость от протоколов более низкого уровня, использование стандартного и существующего программного обеспечения и аппаратных средств для контроля трафика и т.п. Но есть и свои недостатки, например, текстовая природа HTTP. Протокол изначально задумывался для передачи текстовых HTML-документов, но его стали применять и для других видов Web-трафика. Не стоит забывать, несмотря на универсализм HTTP, по-прежнему широко используются и более узкоспециализированные протоколы — FTP, SMTP, NNTP, POP и др. Они хорошо себя зарекомендовали, заняв свою нишу в современной Сети, и было бы неоправданно заменять их все одним лишь HTTP.

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

Заключение

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

Литература

Илья Бочков (preacher@mail.ru) — специалист Московского инженерно-физического института.