Журнал ВРМ World

Мировая история развития технологий управления эффективностью бизнеса – обзоры зарубежных публикаций

Обзор стандарта UDDI

Рубрика "Технологии XML" этого номера Журнала целиком посвящена стандарту
UDDI (Universal Description, Discovery and Integration, Универсальное описание,
обнаружение и интеграция). Эта спецификация является основой, на которой
строятся Web-службы, и признание UDDI является необходимым условием развития и
распространения служб. Мы уже писали об этом стандарте в 9-м номере Журнала и
освещали новости UDDI за май-июнь 2002 года.
Первая статья рубрики знакомит читателя с базовыми элементами стандарта UDDI
и способами их использования. В ней также рассмотрены два основных класса API:
Publish API и Inquiry API, предназначенные для регистрации и поиска служб в
UDDI-регистре, соответственно, и предложен конкретный пример реализации
спецификации для некой гипотетической компании.

Эта статья посвящена бурно развивающемуся стандарту Универсального описания, обнаружения и интеграции (Universal Description, Discovery and Integration, UDDI), предназначенному для определения, регистрации и обнаружения Web-служб, предлагаемых компаниями. Кратно, UDDI - это спецификация, устанавливающаяся требования к распределенному информационному регистру Web-службы. Ниже я расскажу о том, как можно использовать эти регистры, и как с их приходом расширились возможности технологии WWW.

Краткое введение

С Web-службами связаны большие надежды. В связи с чем возникает вопрос: так что же такое Web-службы? Согласно определению, данному консалтинговой компанией The Stencil Group, это "свободно связанные, многократно используемые и, кроме того, распределенные компоненты, которые семантически инкапсулируют дискретную функциональность, и к которым можно программно обращаться посредством стандартных Интернет-протоколов". Web-службы - это новая парадигма в развитии распределенных систем, которая обеспечит в Интернете платформу для всех будущих транзакций электронной коммерции по схеме "бизнес-бизнес" (B2B), а также окончательно установит повсеместно признанный подход к интеграции B2B.

По причине огромного количества различных платформ, средств, алгоритмов и процессов взаимное общение компаний на уровне приложений всегда было непростой задачей. Недавний бум XML объясняется тем, что данный язык представляется крайне обещающим решением с точки зрения бесшовного обмена данными. Кроме того, развитие стандартов, например Simple Object Access Protocol (SOAP), создает благоприятную почву для развития великолепной оболочки, благодаря которой можно вызывать через сеть службы различных компаний. Отлично, у нас есть механизм, с помощью которого компании согласовали, что они будут говорить друг другу (XML) и как они собираются разговаривать (SOAP), но каким образом они узнают с кем общаться и где найти своих партнеров? Представляем UDDI.





Рис. 1. Стек протоколов Web-служб

На рисунке 1 показано, какое место занимает UDDI среди других протоколов в стеке Web-служб. Ниже приведено краткое описание протоколов, представленных в этом стеке:

  • Обычные Интернет-протоколы, например HHTP (и даже в определенной степени SMTP) предоставляют основную коммуникационную оболочку для Web-служб, хотя Web-службы вовсе необязательно связывать с одним из этих протоколов.
  • XML стремительно становится общепризнанным стандартом обмена данными и их структурами, образуя основу Web-служб. Предполагается, что читатель имеет общие представления об этом языке. Отличное ведение в XML: "Суть XML: Необходимые компоненты современных Web-приложений".
  • SOAP предоставляет простой и удобный механизм обмена структурированной и типизированной информацией в децентрализованной, распределенной среде с использованием XML. Предполагается, что читатель имеет общие представления об этом стандарте. Для более подробного знакомства с SOAP рекомендую познакомится с "Обзором стандарта SOAP".
  • UDDI описывает способ опубликования и обнаружения информации о Web-службах. Покров UDDI-регистра (UDDI registry cloud), или бизнес-регистр, предоставляет доступ к информации о Web-службах по схеме "зарегистрируйся один раз, будешь опубликован везде".

Необходимо отметить, что UDDI/SOAP не являются единственными моделями обнаружения и передачи сообщений Web-службам. Так, ebXML был разработан для аналогичных целей, помимо прочего, он предназначался для обеспечения интерфейса бизнес-приложений, решения вопросов безопасности и реализации других функций, необходимых для реальных транзакций электронной коммерции. EbXML и UDDI/SOAP являются конкурирующими технологиями, и вполне возможно, что в будущем они сольются в один стандарт.

UDDI: что это - реальность или еще одна аббревиатура?

Как следует из самого названия, стандарт UDDI предлагает механизм, с помощью которого компании могут "описывать" самих себя и свои услуги, а затем регистрировать и публиковать себя в UDDI-регистре. Другие организации могут искать такие опубликованные компании, обращаться к ним с запросом, или же "обнаруживать" их посредством SOAP-сообщений. После обнаружения подходящих партнеров организации, используя этот механизм, могут "интегрировать" с будущими партнерами свои услуги и предоставлять их своим клиентам.

Представим себе некую компанию ZipZapZoom Courier, специализирующуюся в поставках грузов на территории США. Она могла бы создать Web-службу, с помощью которой часть клиентов этой компании - большинство розничных Интернет-торговцев - могла бы подсчитывать стоимость доставки какого-либо изделия из точки А в точку В при известном весе этого изделия и типе запрашиваемой услуги. Компания могла бы либо разработать SOAP-обертку существующего алгоритма определения расходов для этой поставки, либо переписать ее код и поставлять SOAP-сообщения. Затем эту службу можно было бы опубликовать в UDDI-регистре, чтобы клиенты могли к ней обращаться. Так, любой розничный Интернет-торговец, используя эту Web-службу, мог бы подсчитать, сколько ему нужно запросить с покупателя за доставку. Наконец, эти торговцы могли бы выбрать и услуги другого поставщика, Vroom Shipping - конкурента ZipZapZoom Courier, если бы эта компания также опубликовала свои услуги.

"Белые, желтые и зеленые страницы"

В соответствии с концепцией UDDI, информация, предоставляемая при регистрации бизнеса, распределяется по трем следующим компонентам:

  • "Белые страницы" очень напоминают телефонную книгу и включают адрес, контактную информацию и известные идентификаторы. Компания ZipZapZoom Courier могла бы представить себя следующим образом:

    ZipZapZoom, 123, Swift Drive, Pacer CU
  • "Желтые страницы" также сходны с телефонным эквивалентом и охватывают распределения по отраслевым категориям, основанным на стандартных таксономиях, таких как NAICS (North American Industry Classification System, Система отраслевой классификации Северной Америки), UN/SPC (Dun and Bradstreet's United Nations/Standard Products and Services Classification, индикаторы компании "Дан энд Брэдстрит" для ООН/ Стандартная классификация продуктов и услуг), код SIC (Standard Industrial Classification, Стандартная отраслевая классификация) и так далее. Регистрация такой информации, как отраслевые коды, коды продуктов, географические коды и коды идентификации бизнеса (например, числа D-U-N-S, назначаемые компанией Dun & Bradstreet), позволяет другим поисковым службам использовать базовую классификационную информацию в качестве отправной точки для усовершенствования индексирования и классифицирования. Так, согласно классификации NAICS, Компания ZipZapZoom могла бы отнести себя к категории "Служба поставок и перевозок грузов", находящейся в подкатегории "Курьеры" в категории "Транспортировка и складские помещения" (номер 49211 в категории NAICS).
  • "Зеленые страницы" содержат техническую информацию о службах, представляемых компанией. Они включают ссылки на спецификации для Web-служб, а, при необходимости, также поддержку указателей на различные файлы и механизмы обнаружения, основанные на URL. Узлы UDDI-регистров хранят предшествующую информацию и дублируют окружающие данные для того, чтобы предоставлять такой же каталог информации из любого узла. Эта система напоминает архитектуру DNS, используемую при поиске доменных имен в сети Интернет.

Базовые структуры UDDI

Информация, которая используется при регистрации, состоит из четырех типов структур данных. (необходимая поправка: в второй версии UDDU их стало уже пять). На рисунке 2 показано, как эти структуры образуют спецификацию UDDI.




Рис. 1. Стек протоколов Web-служб

Каждая из этих четырех XML-структур содержит ряд полей, используемых для описания бизнеса или технологических аспектов. Подробное объяснение каждой из этих структур можно найти в справочном документе по структурам данных UDDI. Эти структуры также описаны в спецификации UDDI API Programmer's API и в XML Schema.

Как видно из рисунка (сплошные жирные и пунктирные линии), структура businessEntity содержит одну или несколько уникальных структур businessService. Аналогично, отдельные структуры businessService вмещают определенные экземпляры данных bindingTemplate, которые в свою очередь включают указатели на определенные экземпляры структур tModel. UML-схема этих структур описана в Моделировании UDDI Schema посредством UML.

Давайте подробно остановимся на каждой из этих структур:

  • businessEntity (бизнес-сущность): данная структура захватывает информацию о бизнесе или компании и используется компанией для описания и публикации информации о себе и о предлагаемых услугах. С точки зрения XML, businessEntity - структура данных высшего уровня, которая включает информацию о бизнесе или компании. В businessEntity выражаются описания услуги и техническая информация. Структура businessEntity имеет уникальный ключ, который устанавливает бизнес и данные, которые обычно находятся в "Желтых" и "Белых страницах". Ниже приведен пример того, как могла бы выглядеть структура businessEntity для компании ZipZapZoom Courier, если известна контактная информация исполнительного директора и главного управляющего (г-н Спиди (Sir Gpeedy)):

    <businessEntity authorizedName="0100003PAJ"
      operator="www.ibm.com/services/uddi"
       businessKey="83B31400-7581-11D5-
        889B-0004AC49CC1E">
    <discoveryURLs>
    <discoveryURL useType="businessEntity">
      http://www-3.ibm.com/services/uddi/
       testregistry/uddiget?businessKey=
        83B31400-7581-11D5-889B-0004AC49CC1E
    </discoveryURL>
    </discoveryURLs>
    <name>ZipZapZoom Courier</name>
    <description xml:lang="en">
      Fast and reliable Shipment services
    </description>
    <contacts>
    <contact useType="CEO,COO">
    <description xml:lang="en">
      All-in-All of the company</description>
    <personName>Sir Speedy</personName>
    <phone useType="Work">
      123-456-7890</phone>
    <email useType="">
      sirspeedy@zipzapzoom.com</email>
    </contact>
    </contacts>

  • businessService (сервис информация): эта структура обозначает услуги или бизнес-процессы, обеспечиваемые businessEntity. Обычно она содержит уникальный ключ, используемый для представления этой услуги, а также понятное человеку имя службы, факультативное описание и структуры bindingTemplate, которые содержат техническую информацию.
  • bindingTemplate (связывающий шаблон): данная структура представляет данные, необходимые для описания технических характеристик реализации данной службы. Специалисты IT-отдела располагают информацией, требующейся для вызова службы. Каждый bindingTemplate имеет одного логического родителя businessService, который в свою очередь имеет одного родителя businessEntity. Кроме того, у каждого bindingTemplate имеется уникальный связующий ключ, объединённый служебный ключ (associate service key), и, самое главное, - accessPoint и tModelInstanceDetails. accessPoint представляет адрес для вызова данной Web-службы. Это может быть URL, адрес электронной почты или - вы не поверите - просто телефонный номер.
  • tModel (информация о спецификациях для предоставления служб): основная задача tModel - представлять техническую спецификацию. В спецификации UDDI написано: "Цель tModel в пределах UDDI-регистра - обеспечение справочной системы, основанной на абстракции". Она принимает форму "метаданных по ключу (Keyed metadata)". TModel включает ключ, имя, факультативное описание и URL, по которому можно извлечь информацию о данных. Примером TModel могла бы служить спецификация, описывающая протокол соединений. Ссылка на TModel - залог того, что компания, выставляющая web-службу, реализовала ее так, что она совместима с этой TModel. Таким образом, большинство компании может предоставлять Web-службы, совместимые с одними и теми же спецификациями.

В приведенном ниже примере службы определения стоимости поставки, предоставляемой компанией ZipZapZoom по телефону, описана структура businessService, содержащая структуры bindingTemplate и tModel:


<businessServices>
<businessService serviceKey="
  7BB589E0-7586-11D5-889B-0004AC49CC1E"
   businessKey="83B31400-7581-11D5-
    889B-0004AC49CC1E">
<name>calculateShipping</name>
<description xml:lang="en">
  Given the type of service and the weight,
   the shipping cost is calculated</description>
<bindingTemplates>
<bindingTemplate bindingKey="
  7BB6C260-7586-11D5-889B-0004AC49CC1E"
   serviceKey="7BB589E0-7586-
    11D5-889B-0004AC49CC1E">
<description xml:lang="en">
  The shipping cost can be obtained by
   calling the given number
</description>
<accessPoint URLType="phone">
  123-456-7890</accessPoint>
<tModelInstanceDetails>
<tModelInstanceInfo tModelKey="UUID:
  38E12427-5536-4260-A6F9-B5B530E63A07" />
</tModelInstanceDetails>
</bindingTemplate>


Полную структуру XML (в которой приведены все структуры) можно просмотреть либо в окне браузера, либо, сохранив этот файл как XML, в любом текстовом редакторе.

С целью лучшего понимания стандарта я настоятельно советую внимательно изучить этот пример. Кроме того, ниже мы рассмотрим некоторые "вспомогательные" структуры.

Часто используемые функциональные возможности UDDI

UDDI поддерживает два обширных класса API: Publish API и Inquiry API. Publish API предлагает механизм, с помощью которого поставщики служб могут зарегистрировать себя и свои службы в UDDI-регистре. Этот интерфейс позволяет подписчикам служб искать доступные службы. Inquiry API обеспечивает два типа вызовов: механизмы поиска (представляющий собой алгоритм углубления, посредством которого можно начать поиск с самого высокого информационного уровня и продолжить углубляться, пока не найдена требуемая информация) и извлечения, применяемый, когда вся информация, которую необходимо найти в службе, имеется в наличии.

Опубликование

Сообщения в Publish API представляют собой команды, которые используются для опубликования и обновления информации, содержащейся в UDDI-совместимом регистре. Каждая компания должна первоначально выбрать один сайт-оператор (Operator Site), который будет хранить ее информацию. После того как он выбран, эту информацию можно будет только обновлять. Вызов методов в Publish API требует авторизации и выполняется обычно в рамках механизма защиты. HTTPS используется для всех методов в Publish API. Этот интерфейс включает следующие функции:

  • Четыре сообщения для сохранения каждой их четырех структур: save_business, save_service, save_binding, save_tModel. Каждое из этих сообщений "сохранить" (save) принимает в качестве входных данных authToken и один или несколько соответствующих структур. Например, save_business берет в качестве входа одну или несколько структур businessEntity. Или же каждая такая функция "сохранить" будет также принимать в качестве параметра элемент uploadRegister, который может быть разрешен в адресе HTTP URL. URL должен возвращать чистый XML-документ, который содержит только соответствующую структуру, ожидаемую методом "сохранить".
  • Четыре сообщения для удаления каждой из четырех базовых структур: delete_business, delete_service, delete_binding, delete_tModel. Все они принимают соответствующий ключ uuid в качестве параметра. Успешное завершение или сбой сообщений удаления указывается в соответствующем коде возвращаемой SOAP-структуре dispositionReport. Для того, чтобы удалить бизнес, который был создан для компании ZipZapZoom, нам потребовалось бы передать следующую структуру XML:

    <delete_business generic="1.0" xmlns="urn:uddi-org:api" >
      <authInfo>Some auth info here </authInfo>
      <businessKey>83B31400-7581-11D5-889B-0004AC49CC1E
      </businessKey>
    </delete_business>

    Обратите внимание на то, что атрибут businessKey такой же, как и в элементе businessKey в описании businessEntity.
  • get_auth Token: эта функция - программный аналог логина (login). Она используется для запроса опознавательного признака (authentication token) у UDDI-оператора. Все функции Publish API требуют использования этого признака. Пожалуйста, имейте в виду, что эта функция считается факультативной, и поэтому UDDI-операторы, предоставляющие иной механизм аутентификации - например алгоритм, основанный на регистрации пользовательских ID/паролей - необязательно ее реализуют.
  • discard_authToken: данная функция используется для информирования UDDI-регистра о том, что authToken больше не является действующей.
  • get_registeredInfo: эта функция предназначена для выдачи короткого резюме обо всей информации (особенно, о ключах businessEntity и tModel).

Поиск

Эти сообщения в Inquiry API представляют запросы, с которыми можно обращаться к UDDI-регистру, и могут быть распределены по двум категориям, а именно: просмотр и углубление:

  • Просмотр: UDDI поддерживает четыре типа обращений для этой модели, и, как нетрудно догадаться, по одному для каждого из четырех типов данных. find_business обычно, вызывается, когда доступна любая частная информация, и возвращает структуру businessList, которая является укороченным набором ключевой информации из структуры businessEntity. Для подходящего совпадения можно несколько раз проходить через BusinessList, а затем использовать сообщение find_service для того, чтобы получить отдельные типы службы. Каждое из этих обращений "поиск" (find) принимает также факультативный элемент findQualifiers, который меняет метод поиска, используемый по умолчанию. Примерами findQualifiers являются "exactNameMatch", "caseSensitiveMatch", "sortByNameAsc" и так далее. Эти вызовы "поиск" поддерживают атрибут maxRows, который определяет максимальное число возвращаемых результатов поиска.
  • Углубление: если доступен ключ для одного из четырех основных типов данных, этот ключ можно использовать для получения информации, касающейся отдельного экземпляра этого типа данных. Этот вызов "получить" (get) применяется для получения информации, относящейся к любому типу данных для данного ключа. Таким образом, это вызовы: get_businessDetail, get_serviceDetail, get_bindingDetail, get_tModelDetail и, наконец, get_businessDetailExt, который предоставляет подробную информацию о businessEntity.

Модели связывания и вызова

Для того, чтобы вызвать службу, зарегистрированную в UDDI-регистре, необходимо, чтобы приложение знало о ее существовании. Эти данные обычно включаются в приложение во время разработки. Подобные данные о вызове, как мы уже видели, содержатся в типе данных "bindingTemplate", их необходимо кэшировать и использовать во время вызова; таким образом, при повторяющихся обращениях к службе, описанной посредством bindingTemplate, необязательно повторно обращаться к UDDI-регистру. Этот механизм, однако, привел бы к ситуации, при которой удаленная служба оказалась бы повторно обнаруженной без уведомления о клиенте (например, во время замены ПО на новую версию). Чтобы корректно выполнить это, следует:

  • Вызвать передачу get_bindingDetail в кэшированном bindingTemplate.
  • Проверить данные, возвращенные get_bindingDetail, и вызвать службу, используя "новый" bindingTemplate, если данные, возвращенные get_bindingDetail, отличаются от кэшированной информации.
  • Если вызов оказался удачным, заменить кэшированную информацию на новую.

Подводя итоги: пример приложения

После того, как мы рассмотрели все основные положения UDDI, я предлагаю посмотреть, как можно вызвать сообщение "поиск" для бизнеса компании ZipZapZoom Courier, которое компания создала IBM в UDDI-регистре тестирования специально для данной статьи.

Для получения информации о том, как зарегистрироваться в этом регистре и и как создать свой бизнес, обращайтесь по следующему адресу:

http://www6.software.ibm.com/developerworks/education/ws~rpws/index.html./p>

Пожалуйста, обратите внимание на то, что, чтобы получить доступ на этот сайт, вы должны быть авторизованы.

Я использовал следующую реализацию UDDI: IBM UDDI4J. Более подробную информацию, а также вопросы, касающиеся установки IBM UDDI4J, можно найти, посмотрев Проект UDDI4J.

Центральным в реализации IBM UDDI4J является класс UDDIProxy, который используется для взаимодействия с UDDI-регистром. Псевдо-код для моего приложения может иметь следующий вид:

  • Приписать значение UDDIProxy.
  • Сконфигурировать его для доступа к подходящему UDDI-регистру.
  • Вызвать метод find_business.
  • Просмотреть несколько раз результаты, чтобы найти требуемый бизнес.

Я определил при помощи методов setInquiryURL() и setPublishURL() следующие регистры для регистрации и опубликования, соответственно:


myProxy.setInquiryURL("http://www-3.ibm.com/
  services/uddi/testregistry/inquiryapi");


Класс UDDIProxy предоставляет метод find_business(), который может рассматриваться как обертка Java для сообщения find_business(), о котором я упоминал ранее.


zipzapList = myProxy.find_business("ZipZapZoom", null, 0);

Он принимает три параметра: параметр "искать", параметр "найти" и предел поиска. Метод возвращает объект типа BusinessList, из которого я могу обратиться к требуемой информации для этого бизнеса. Полностью исходный код и документацию можно найти по следующему адресу:


FindZipZapZoom.java и FindZipZapZoom.class.

Заключение

Данная статья посвящена техническим аспектам UDDI, бурно развивающегося стандарта, предназначенного для нахождения компаний и вызова сервисов, которые они предлагают. В ней подробно освещены базовые структуры UDDI, рассказывается о наиболее распространенных способах их использования, а также показана реализация спецификации UDDI на примере приложения find_business.

Автор: Ананд Раджарам (Anand Rajaram)