Во времена моего детства в магазинах продавался суп Chef Boyardee с вермишелью в форме букв алфавита. Мне этот суп очень нравился, и я часто просил родителей покупать его — причудливые плавающие буквы казались чем-то новым, крутым и забавным. Однако родители знали, как знаем мы с вами сейчас, что то были всего лишь обычные макаронины, плавающие в прозаическом бульоне. Нынешняя ситуация в области технологий сильно напоминает такой же суп из Web-служб и связанных с ними аббревиатур. И хотя многое из того, что «умеет» этот «суп», не представляет собой ничего нового, но так или иначе Web-службы вызывают детский восторг у корпоративного сообщества.

Тем не менее некоторые вещи в этом «супе» из аббревиатур не так уж и плохи, несмотря на некоторую тяжеловатость и медлительность. У нас появился язык XML, который не только используется в контексте Web-служб, но еще умеет описывать данные во многих других предметных областях. Некоторые ведущие организации по стандартизации, такие, как World Wide Web Consortium и OASIS, не боятся своей репутацией гарантировать успех XML в качестве всемирного стандарта.

В конечном счете во всяком разговоре о Web-службах упоминается «святая троица» аббревиатур, в которых, как предполагается, и заключен смысл существования Web-служб. Две из них — язык описания Web-служб (Web Services Description Language, WSDL) и простой протокол доступа к объектам (Simple Object Access Protocol, SOAP) — в действительности относительно просты в плане структуры и области применения и в настоящее время активно используются во многих новых стратегических бизнес-приложениях. И снова хочется сказать, что концепции, лежащие в основе этих двух компонентов, составляют базу любой распределенной структуры и определяют порядок описания или вызова универсальных, совместимых со многими языками интерфейсов. О третьей аббревиатуре, этакой бедной падчерице, много говорят, но встретить ее в реальной жизни удается не часто. Речь идет об UDDI (Universal Description, Discovery and Integration) — универсальной технологии описания, обнаружения и интеграции Web-служб, вокруг которой сейчас концентрируется основная шумиха, связанная с Web-службами.

Еще одна история о Золушке?

Возможно, история UDDI похожа на сказку о Золушке, которую держат «в черном теле» две злые сестры. Не исключено также, что в один прекрасный день ее хрустальную XML-туфельку найдет какой-нибудь корпоративный принц и она станет самой главной принцессой Web-служб — на что, собственно, UDDI сейчас и претендует. Естественно, если она успеет вернуться домой до того, как часы маркетинговой «раскрутки» пробьют полночь и карета превратится в большую тыкву. Впрочем, может быть, UDDI никак не выйдет на сцену из-за того, что официальные организации, отвечающие за стандартизацию, не взялись за нее как следует или потому что Microsoft и IBM действительно не понимают нужд и потребностей масс. В любом случае вся затея с UDDI медленно выдыхается.

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

Стандарты создаются для того, чтобы обеспечить взаимодействие разнородных систем. Но что плохого в том, если одна компания предоставит своим партнерам возможность искать ее сервисы с применением методов или форматов, которые немного отличаются от используемых другой компанией? Вы можете возразить, что это неправильно и нужно создать универсальный интерфейс реестра, который позволит любой программе стандартно обращаться к UDDI-реестру, стандартным образом находить нужный файл интерфейса (WSDL), а затем стандартно применять правильный контекст для вызова стандартной SOAP-службы. Как видите, мы пришли к некоторой ИТ-версии универсального супермаркета. Но, как и в любом универсальном супермаркете, в UDDI вы не вправе рассчитывать на высочайший уровень сервиса, который доступен только в специализированных магазинах известных марок.

Можно подумать, что удастся динамически найти в UDDI-реестре интерфейс службы, а затем автоматически — без привлечения разработчиков — получить доступ к SOAP-серверу из внутренней системы, но на самом деле это невозможно. Допустим, вы обратились к некоторой службе погоды с интерфейсом, который принимает две строковые переменные и возвращает одну переменную с плавающей точкой. Но как узнать смысл этой пары строковых — долгота и широта? название города и почтовый индекс? температура и влажность? а если это температура — то по Фаренгейту или по Цельсию?

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

Тыква

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

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

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

Сегодня уже есть ряд общедоступных UDDI-реестров. Например, большой открытый реестр UDDI Business Registry корпорации IBM расположен на странице http://www-3.ibm.com/services/uddi/find. У Microsoft, Hewlett-Packard и SAP также есть ряд крупных реестров. Однако, просматривая их содержимое, очень трудно разобраться, какая часть из опубликованных в этих реестрах служб действительно полезна, а что — просто мусор. В конце концов все равно приходится искать нужную информацию в других местах.

Сейчас появляется великое множество других стандартов реестров: electronic business XML (активно продвигается как замена технологиям EDI) и Java API for XML Registries, или JAXR (стандартный Java-интерфейс Sun для XML-реестров). Любой из этих реестров при необходимости может размещаться поверх UDDI API. Однако ни одна из этих новых диковинных птичек пока так и не научилась летать.

И жили они счастливо…

Ирония судьбы в том, что в Google, одной из ведущих поисковых машин, недавно решили создать интерфейс к поисковому «движку» в виде Web-службы. Этот интерфейс позволит разработчикам интегрировать Web-поиск любого вида в создаваемые ими стратегические бизнес-приложения. Естественно, Google не пришлось регистрировать свою службу в каком бы то ни было UDDI-реестре — пользователи и так найдут ее и узнают, как с ней работать. И хотя Google всегда была гадким утенком в мире поисковых машин, так как не обладала эффектным интерфейсом, это никак не мешало ей предоставлять пользователям именно то, что нужно.

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

Майкл Дж. Хадсон (Michael J. Hudson) — инженер по инфраструктуре в компании Blueprint Technologies (Маклин, штат Виргиния). В настоящее время занимается разработкой корпоративных архитектурных решений для таких клиентов, как NASA. С ним можно связаться по e-mail: mhudson@blueprinttech.com.

Источники информации

EbXMLhttp://www.ebxml.org
Google Web APIshttp://www.google.com/apis
IBM UDDI Business Registryhttp://www-3.ibm.com/services/uddi/find
Информационный центр по Web-службам на сайте IntelligentEnterprise.comhttp://www.intelligententerprise.com/info_centers/web_services
JAXRjava.sun.com/xml/jaxr
OASIShttp://www.oasis-open.org
UDDIhttp://www.uddi.org
World Wide Web Consortiumhttp://www.w3.org

Статьи по теме в Intelligent Enterprise

«Семантическая паутина», Intelligent Enterprise № 9’2002
«Единым фронтом», Intelligent Enterprise № 10’2002