UDDI — Обзор

UDDI — это основанный на XML стандарт для описания, публикации и поиска веб-сервисов.

• UDDI расшифровывается как универсальное описание, обнаружение и интеграция.

• UDDI — это спецификация для распределенного реестра веб-сервисов.

• UDDI — это независимая от платформы открытая структура.

• UDDI может взаимодействовать через SOAP, CORBA, протокол Java RMI.

• UDDI использует язык определения веб-служб (WSDL) для описания интерфейсов веб-служб.

• UDDI рассматривается в SOAP и WSDL как один из трех основных стандартов веб-сервисов.

• UDDI — это открытая отраслевая инициатива, позволяющая компаниям узнавать друг друга и определять, как они взаимодействуют через Интернет.

UDDI расшифровывается как универсальное описание, обнаружение и интеграция.

UDDI — это спецификация для распределенного реестра веб-сервисов.

UDDI — это независимая от платформы открытая структура.

UDDI может взаимодействовать через SOAP, CORBA, протокол Java RMI.

UDDI использует язык определения веб-служб (WSDL) для описания интерфейсов веб-служб.

UDDI рассматривается в SOAP и WSDL как один из трех основных стандартов веб-сервисов.

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

UDDI имеет два раздела —

• Реестр всех метаданных веб-службы, включая указатель на WSDL-описание службы.

• Набор определений типов портов WSDL для управления этим реестром и его поиска.

Реестр всех метаданных веб-службы, включая указатель на WSDL-описание службы.

Набор определений типов портов WSDL для управления этим реестром и его поиска.

История UDDI

• UDDI 1.0 был первоначально анонсирован Microsoft, IBM и Ariba в сентябре 2000 года.

• Со времени первого объявления инициатива UDDI расширилась и включает более 300 компаний, включая Dell, Fujitsu, HP, Hitachi, IBM, Intel, Microsoft, Oracle, SAP и Sun.

• В мае 2001 года Microsoft и IBM запустили первые сайты операторов UDDI и запустили реестр UDDI.

• В июне 2001 года UDDI анонсировала версию 2.0.

• На момент написания этого руководства сайты Microsoft и IBM внедрили спецификацию 1.0 и планировали поддержку 2.0 в ближайшем будущем.

• В настоящее время UDDI спонсируется OASIS.

UDDI 1.0 был первоначально анонсирован Microsoft, IBM и Ariba в сентябре 2000 года.

Со времени первого объявления инициатива UDDI расширилась и включает более 300 компаний, включая Dell, Fujitsu, HP, Hitachi, IBM, Intel, Microsoft, Oracle, SAP и Sun.

В мае 2001 года Microsoft и IBM запустили первые сайты операторов UDDI и запустили реестр UDDI.

В июне 2001 года UDDI анонсировала версию 2.0.

На момент написания этого руководства сайты Microsoft и IBM внедрили спецификацию 1.0 и планировали поддержку 2.0 в ближайшем будущем.

В настоящее время UDDI спонсируется OASIS.

Процессы партнерского интерфейса

Партнерские интерфейсные процессы (PIP) — это интерфейсы на основе XML, которые позволяют двум торговым партнерам обмениваться данными. Десятки ПИПов уже существуют. Некоторые из них перечислены здесь —

• PIP2A2 — позволяет партнеру запрашивать информацию о продукте у другого.

• PIP3A2 — позволяет партнеру запрашивать цену и доступность определенных продуктов.

• PIP3A4 — позволяет партнеру подать электронный заказ на покупку и получить подтверждение заказа.

• PIP3A3 — позволяет партнеру передавать содержимое электронной корзины.

• PIP3B4 — позволяет партнеру запрашивать статус конкретной отправки.

PIP2A2 — позволяет партнеру запрашивать информацию о продукте у другого.

PIP3A2 — позволяет партнеру запрашивать цену и доступность определенных продуктов.

PIP3A4 — позволяет партнеру подать электронный заказ на покупку и получить подтверждение заказа.

PIP3A3 — позволяет партнеру передавать содержимое электронной корзины.

PIP3B4 — позволяет партнеру запрашивать статус конкретной отправки.

Частные реестры UDDI

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

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

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

UDDI — Элементы

Бизнес или компания могут зарегистрировать три типа информации в реестре UDDI. Эта информация содержится в трех элементах UDDI.

Эти три элемента —

• Белые страницы,
• Желтые страницы и
• Зеленые Страницы.

Белые страницы

Белые страницы содержат —

• Основная информация о компании и ее бизнесе.

• Основная контактная информация, включая название компании, адрес, контактный телефон и т. Д.

• Уникальные идентификаторы для налоговых идентификаторов компании. Эта информация позволяет другим пользователям обнаруживать ваш веб-сервис на основе вашей бизнес-идентификации.

Основная информация о компании и ее бизнесе.

Основная контактная информация, включая название компании, адрес, контактный телефон и т. Д.

Уникальные идентификаторы для налоговых идентификаторов компании. Эта информация позволяет другим пользователям обнаруживать ваш веб-сервис на основе вашей бизнес-идентификации.

Желтые страницы

• Желтые страницы содержат более подробную информацию о компании. Они включают описания электронных возможностей, которые компания может предложить любому, кто хочет иметь с ней дело.

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

Желтые страницы содержат более подробную информацию о компании. Они включают описания электронных возможностей, которые компания может предложить любому, кто хочет иметь с ней дело.

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

Зеленые страницы

Зеленые страницы содержат техническую информацию о веб-сервисе. Зеленая страница позволяет кому-либо связываться с веб-сервисом после его обнаружения. Включает в себя —

• Различные интерфейсы
• Расположение URL
• Информация об обнаружении и аналогичные данные, необходимые для поиска и запуска веб-службы.

ПРИМЕЧАНИЕ. — UDDI не ограничивается описанием веб-служб на основе SOAP. Скорее UDDI можно использовать для описания любой службы, от одной веб-страницы или адреса электронной почты до сервисов SOAP, CORBA и Java RMI.

UDDI — Техническая Архитектура

Техническая архитектура UDDI состоит из трех частей:

Модель данных UDDI

Модель данных UDDI — это XML-схема для описания предприятий и веб-сервисов. Модель данных подробно описана в главе «Модель данных UDDI».

Спецификация UDDI API

Это спецификация API для поиска и публикации данных UDDI.

UDDI облачные сервисы

Это операторские сайты, которые предоставляют реализации спецификации UDDI и синхронизируют все данные по расписанию.

UDDI Business Registry (UBR), также известная как Public Cloud, является концептуально единой системой, построенной из нескольких узлов, синхронизирующих свои данные посредством репликации.

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

Облачные сервисы UDDI в настоящее время предоставляются Microsoft и IBM. Изначально Ariba планировала также предложить оператора, но с тех пор отказалась от обязательств. Дополнительные операторы от других компаний, включая Hewlett-Packard, запланированы на ближайшее будущее.

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

UDDI — модель данных

UDDI включает в себя XML-схему, которая описывает следующие структуры данных:

• субъект предпринимательской деятельности
• бизнес Сервис
• bindingTemplate
• TModel
• publisherAssertion

Структура данных businessEntity

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

Вот пример записи реестра UDDI фиктивного бизнеса —

<businessEntity businessKey = "uuid:C0E6D5A8-C446-4f01-99DA-70E212685A40"
   operator = "http://www.ibm.com" authorizedName = "John Doe">
   <name>Acme Company</name>
   <description>
      We create cool Web services
   </description>
	
   <contacts>	
      <contact useType = "general info">
         <description>General Information</description>
         <personName>John Doe</personName>
         <phone>(123) 123-1234</phone>
         <email>[email protected]</email>
      </contact>		
   </contacts>
	
   <businessServices>
      ...
   </businessServices>
   <identifierBag>	
      <keyedReference tModelKey = "UUID:8609C81E-EE1F-4D5A-B202-3EB13AD01823" 
         name = "D-U-N-S" value = "123456789" />
   </identifierBag>
	
   <categoryBag>	
      <keyedReference tModelKey = "UUID:C0B9FE13-179F-413D-8A5B-5004DB8E5BB2" 
         name = "NAICS" value = "111336" />			
   </categoryBag>		
</businessEntity>

Структура данных businessService

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

Вот пример структуры бизнес-сервиса для веб-сервиса Hello World.

<businessService serviceKey = "uuid:D6F1B765-BDB3-4837-828D-8284301E5A2A"
   businessKey = "uuid:C0E6D5A8-C446-4f01-99DA-70E212685A40">
   <name>Hello World Web Service</name>
   <description>A friendly Web service</description>
   <bindingTemplates>
      ...
   </bindingTemplates>
   <categoryBag />
</businessService>

Обратите внимание на использование универсально уникальных идентификаторов (UUID) в атрибутах businessKey и serviceKey . Каждый бизнес-объект и бизнес-сервис однозначно идентифицируются во всех реестрах UDDI через UUID, назначенный реестром при первом вводе информации.

Структура данных bindingTemplate

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

Вот пример шаблона привязки для Hello World.

<bindingTemplate serviceKey = "uuid:D6F1B765-BDB3-4837-828D-8284301E5A2A"
   bindingKey = "uuid:C0E6D5A8-C446-4f01-99DA-70E212685A40">
   <description>Hello World SOAP Binding</description>
   <accessPoint URLType = "http">http://localhost:8080</accessPoint>
   
   <tModelInstanceDetails>
      <tModelInstanceInfo tModelKey = "uuid:EB1B645F-CF2F-491f-811A-4868705F5904">
         <instanceDetails>
            <overviewDoc>
               <description>
                  references the description of the WSDL service definition
               </description>
               
               <overviewURL>
                  http://localhost/helloworld.wsdl
               </overviewURL>
            </overviewDoc>
         </instanceDetails>
      </tModelInstanceInfo>
   </tModelInstanceDetails>
</bindingTemplate>

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

Структура данных tModel

tModel является последним основным типом данных, но потенциально наиболее трудным для понимания. tModel обозначает техническую модель.

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

Вот пример tModel, представляющего тип порта Hello World Interface.

<tModel tModelKey = "uuid:xyz987..." operator = "http://www.ibm.com" 
   authorizedName = "John Doe">
   <name>HelloWorldInterface Port Type</name>
   <description>
      An interface for a friendly Web service
   </description>
	
   <overviewDoc>
      <overviewURL>
         http://localhost/helloworld.wsdl
      </overviewURL>
   </overviewDoc>
</tModel>

Структура данных publisherAssertion

Это структура отношений, объединяющая две или более структур businessEntity в соответствии с определенным типом отношений, таким как дочерняя компания или отдел.

Структура publisherAssertion состоит из трех элементов: fromKey (первый businessKey), toKey (второй businessKey) и keyedReference.

KeyedReference обозначает тип утвержденного отношения в терминах пары keyName keyValue в tModel, на которую уникально ссылается tModelKey.

<element name = "publisherAssertion" type = "uddi:publisherAssertion" />
<complexType name = "publisherAssertion">
   <sequence>
      <element ref = "uddi:fromKey" />
      <element ref = "uddi:toKey" />
      <element ref = "uddi:keyedReference" />
   </sequence>
</complexType>

UDDI — Интерфейсы

Реестр бесполезен без какого-либо способа доступа к нему. Версия 2.0 стандарта UDDI определяет два интерфейса для взаимодействия потребителей и поставщиков услуг с реестром.

Потребители услуг используют интерфейс запросов для поиска услуг, а поставщики услуг используют интерфейс издателей для составления списка услуг.

Ядром интерфейса UDDI являются определения XML-схемы UDDI. Они определяют основные типы данных UDDI, через которые проходит вся информация.

Интерфейс издателя

Интерфейс издателя определяет шестнадцать операций для поставщика услуг, управляющего его записями в реестре UDDI —

• get_authToken — получает токен авторизации. Все операции интерфейса Publisher требуют, чтобы с запросом был представлен действительный токен авторизации.

• discard_authToken — Указывает реестру UDDI больше не принимать данный токен авторизации. Этот шаг эквивалентен выходу из системы.

• save_business — создает или обновляет информацию бизнес-объекта, содержащуюся в реестре UDDI.

• save_service — создает или обновляет информацию о веб-сервисах, которые предоставляет бизнес-объект.

• save_binding — создает или обновляет техническую информацию о реализации веб-службы.

• save_tModel — создает или обновляет регистрацию абстрактных концепций, управляемых реестром UDDI.

• delete_business — полностью удаляет указанные бизнес-объекты из реестра UDDI.

• delete_service — полностью удаляет указанные веб-сервисы из реестра UDDI.

• delete_binding — удаляет указанные технические данные веб-служб из реестра UDDI.

• delete_tModel — удаляет указанные tModels из реестра UDDI.

• get_registeredInfo — возвращает сводную информацию обо всем, что реестр UDDI в настоящее время отслеживает для пользователя, включая все предприятия, все службы и все tModels.

• set_publisherAssertions — управляет всеми отслеживаемыми утверждениями отношений, связанными с отдельной учетной записью издателя.

• add_publisherAssertions — вызывает добавление одного или нескольких publisherAssertions в коллекцию утверждений отдельного издателя.

• delete_publisherAssertions — вызывает удаление одного или нескольких элементов publisherAssertion из коллекции утверждений издателя.

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

• get_publisherAssertions — получает полный набор утверждений издателя, связанный с отдельной учетной записью издателя.

get_authToken — получает токен авторизации. Все операции интерфейса Publisher требуют, чтобы с запросом был представлен действительный токен авторизации.

discard_authToken — Указывает реестру UDDI больше не принимать данный токен авторизации. Этот шаг эквивалентен выходу из системы.

save_business — создает или обновляет информацию бизнес-объекта, содержащуюся в реестре UDDI.

save_service — создает или обновляет информацию о веб-сервисах, которые предоставляет бизнес-объект.

save_binding — создает или обновляет техническую информацию о реализации веб-службы.

save_tModel — создает или обновляет регистрацию абстрактных концепций, управляемых реестром UDDI.

delete_business — полностью удаляет указанные бизнес-объекты из реестра UDDI.

delete_service — полностью удаляет указанные веб-сервисы из реестра UDDI.

delete_binding — удаляет указанные технические данные веб-служб из реестра UDDI.

delete_tModel — удаляет указанные tModels из реестра UDDI.

get_registeredInfo — возвращает сводную информацию обо всем, что реестр UDDI в настоящее время отслеживает для пользователя, включая все предприятия, все службы и все tModels.

set_publisherAssertions — управляет всеми отслеживаемыми утверждениями отношений, связанными с отдельной учетной записью издателя.

add_publisherAssertions — вызывает добавление одного или нескольких publisherAssertions в коллекцию утверждений отдельного издателя.

delete_publisherAssertions — вызывает удаление одного или нескольких элементов publisherAssertion из коллекции утверждений издателя.

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

get_publisherAssertions — получает полный набор утверждений издателя, связанный с отдельной учетной записью издателя.

Интерфейс запроса

Интерфейс запроса определяет десять операций для поиска в реестре UDDI и получения сведений о конкретных регистрациях —

• find_binding — возвращает список веб-сервисов, которые соответствуют определенному набору критериев на основе информации о техническом связывании.

• find_business — возвращает список бизнес-объектов, которые соответствуют определенному набору критериев.

• find_ltservice — возвращает список веб-сервисов, которые соответствуют определенному набору критериев.

• find_tModel — возвращает список моделей, которые соответствуют определенному набору критериев.

• get_bindingDetail — возвращает полную регистрационную информацию для конкретного шаблона привязки веб-службы.

• get_businessDetail — возвращает регистрационную информацию для бизнес-объекта, включая все услуги, предоставляемые этим объектом.

• get_businessDetailExt — возвращает полную регистрационную информацию для бизнес-объекта.

• get_serviceDetail — возвращает полную регистрационную информацию для веб-службы.

• get_tModelDetail — возвращает полную регистрационную информацию для tModel.

• find_relatedBususiness — Обнаруживает предприятия, которые были связаны через модель отношений uddi-org :.

find_binding — возвращает список веб-сервисов, которые соответствуют определенному набору критериев на основе информации о техническом связывании.

find_business — возвращает список бизнес-объектов, которые соответствуют определенному набору критериев.

find_ltservice — возвращает список веб-сервисов, которые соответствуют определенному набору критериев.

find_tModel — возвращает список моделей, которые соответствуют определенному набору критериев.

get_bindingDetail — возвращает полную регистрационную информацию для конкретного шаблона привязки веб-службы.

get_businessDetail — возвращает регистрационную информацию для бизнес-объекта, включая все услуги, предоставляемые этим объектом.

get_businessDetailExt — возвращает полную регистрационную информацию для бизнес-объекта.

get_serviceDetail — возвращает полную регистрационную информацию для веб-службы.

get_tModelDetail — возвращает полную регистрационную информацию для tModel.

find_relatedBususiness — Обнаруживает предприятия, которые были связаны через модель отношений uddi-org :.

UDDI — Пример использования

Представьте себе, что компания XYZ хочет зарегистрировать свою контактную информацию, описание услуг и информацию о доступе к онлайн-сервисам в UDDI. Следующие шаги необходимы —

• Выберите оператора для работы. Каждый оператор имеет свои условия предоставления доступа к своей реплике реестра.

• Создайте или иным образом получите клиент UDDI, например, предоставленный операторами.

• Получите токен аутентификации у оператора.

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

• Отпустите маркер аутентификации.

• Используйте API запросов, чтобы проверить получение информации, включая информацию шаблона привязки, чтобы убедиться, что тот, кто ее получит, сможет успешно использовать ее для взаимодействия с вашим сервисом.

• Заполните информацию tModel на тот случай, если кто-то захочет найти данную услугу и найти ваш бизнес в качестве одного из поставщиков услуг.

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

Выберите оператора для работы. Каждый оператор имеет свои условия предоставления доступа к своей реплике реестра.

Создайте или иным образом получите клиент UDDI, например, предоставленный операторами.

Получите токен аутентификации у оператора.

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

Отпустите маркер аутентификации.

Используйте API запросов, чтобы проверить получение информации, включая информацию шаблона привязки, чтобы убедиться, что тот, кто ее получит, сможет успешно использовать ее для взаимодействия с вашим сервисом.

Заполните информацию tModel на тот случай, если кто-то захочет найти данную услугу и найти ваш бизнес в качестве одного из поставщиков услуг.

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

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

Создание реестра

После получения токена аутентификации от одного из операторов Microsoft, например, разработчики XYZ.com решают, какую информацию публиковать в реестре, и используют один из инструментов UDDI, предоставляемых Microsoft. При необходимости разработчики также могут написать программу на Java, C # или VB.NET для генерации соответствующих сообщений SOAP. Вот пример.

POST /save_business HTTP/1.1
Host: www.XYZ.com
Content-Type: text/xml; charset = "utf-8"
Content-Length: nnnn
SOAPAction: "save_business"

<?xml version = "1.0" encoding = "UTF-8" ?>
<Envelope xmlns = "http://schemas/xmlsoap.org/soap/envelope/">
   <Body>
      <save_business generic = "2.0" xmlns = "urn:uddi-org:api_v2">
         <businessKey = "">
         </businessKey>
         
         <name>
            XYZ, Pvt Ltd.
         </name>
         
         <description>
            Company is involved in giving Stat-of-the-art....
         </description>
         
         <identifierBag> ... </identifierBag>
         ...
      </save_business>
   </Body>
</Envelope>

Этот пример иллюстрирует сообщение SOAP, запрашивающее регистрацию бизнес-объекта UDDI для компании XYZ. Элемент ключа пуст, потому что оператор автоматически генерирует ключ UUID для структуры данных. Большинство полей опущены, чтобы показать простой пример.

Компания XYZ всегда может выполнить другую операцию save_business, чтобы добавить основную информацию, необходимую для создания бизнес-объекта.

Получение информации

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

В этом примере показан пример запроса SOAP для получения подробной бизнес-информации о компании XYZ. Когда вы знаете UUID или ключ для конкретной зарегистрированной компании, вы можете использовать ее в API get_businessDetail для получения конкретной информации об этой компании.

POST /get_businessDetail HTTP/1.1
Host: www.XYZ.com
Content-Type: text/xml; charset = "utf-8"
Content-Length: nnnn
SOAPAction: "get_businessDetail"

<?xml version = "1.0" encoding = "UTF-8" ?>
<Envelope xmlns = "http://schemas/xmlsoap.org/soap/envelope/">
   <Body>
      <get_businessDetail generic = "2.0" xmlns = "urn:uddi-org:api_v2">
         <businessKey = "C90D731D-772HSH-4130-9DE3-5303371170C2">
         </businessKey>
      </get_businessDetail>
   </Body>
</Envelope>

UDDI с WSDL

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

Однако WSDL используется для описания интерфейса веб-службы. WSDL довольно прост в использовании с UDDI.

• WSDL представлен в UDDI с использованием комбинации данных businessService, bindingTemplate и tModel .

• Как и для любой службы, зарегистрированной в UDDI, общая информация о службе сохраняется в структуре данных businessService , а информация, относящаяся к тому, как и где осуществляется доступ к услуге, хранится в одной или нескольких связанных структурах bindingTemplate . Каждая структура bindingTemplate включает в себя элемент, который содержит сетевой адрес службы и имеет связанную с ним одну или несколько структур tModel, которые описывают и уникально идентифицируют службу.

• Когда UDDI используется для хранения информации WSDL или указателей на файлы WSDL, tModel должен называться соглашением как тип wsdlSpec , что означает, что элемент OverviewDoc четко идентифицирован как указывающий на определение интерфейса службы WSDL.

• Для UDDI содержимое WSDL разделено на два основных элемента: файл интерфейса и файл реализации.

WSDL представлен в UDDI с использованием комбинации данных businessService, bindingTemplate и tModel .

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

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

Для UDDI содержимое WSDL разделено на два основных элемента: файл интерфейса и файл реализации.

Веб-сервис системы бронирования Hertz предоставляет конкретный пример того, как UDDI и WSDL работают вместе. Вот <tModel> для этого веб-сервиса —

<tModel authorizedName = "..." operator = "..." tModelKey = "...">
   <name>HertzReserveService</name>
   <description xml:lang = "en">
      WSDL description of the Hertz reservation service interface
   </description>
	
   <overviewDoc>
      <description xml:lang = "en">
         WSDL source document.
      </description>
      <overviewURL>
         http://mach3.ebphost.net/wsdl/hertz_reserve.wsdl
      </overviewURL>
   </overviewDoc>
   
   <categoryBag>
      <keyedReference tModelKey = "uuid:C1ACF26D-9672-4404-9D70-39B756E62AB4"
         keyName = "uddi-org:types" keyValue = "wsdlSpec"/>
   </categoryBag>	
</tModel>

Ключевые моменты —

• Элемент OverviewURL дает URL-адрес, по которому можно найти файл WSDL определения интерфейса службы. Это позволяет людям и инструментам, знакомым с UDDI / WSDL, найти определение интерфейса службы.

• Цель элемента keyedReference в categoryBag состоит в том, чтобы убедиться, что этот tModel классифицирован как документ спецификации WSDL.

Элемент OverviewURL дает URL-адрес, по которому можно найти файл WSDL определения интерфейса службы. Это позволяет людям и инструментам, знакомым с UDDI / WSDL, найти определение интерфейса службы.

Цель элемента keyedReference в categoryBag состоит в том, чтобы убедиться, что этот tModel классифицирован как документ спецификации WSDL.

UDDI — Реализации

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

Java реализации

Существует две реализации UDDI для Java.

• UDDI4J (UDDI для Java) — UDDI4J изначально был создан IBM. В январе 2001 года IBM передала код на свой собственный сайт с открытым исходным кодом. UDDI4J — это библиотека классов Java, которая предоставляет API для взаимодействия с UDDI.

• jUDDI — jUDDI — это реализация Java с открытым исходным кодом реестра UDDI и инструментария для доступа к службам UDDI.

UDDI4J (UDDI для Java) — UDDI4J изначально был создан IBM. В январе 2001 года IBM передала код на свой собственный сайт с открытым исходным кодом. UDDI4J — это библиотека классов Java, которая предоставляет API для взаимодействия с UDDI.

jUDDI — jUDDI — это реализация Java с открытым исходным кодом реестра UDDI и инструментария для доступа к службам UDDI.

Реализация Perl

• UDDI :: Lite — предоставляет базовый UDDI-клиент для запросов и публикации.

UDDI :: Lite — предоставляет базовый UDDI-клиент для запросов и публикации.

Реализация Ruby

• UDDI4r — предоставляет базовый UDDI-клиент для запросов и публикации.

UDDI4r — предоставляет базовый UDDI-клиент для запросов и публикации.

Реализация Python

• UDDI4Py — UDDI4Py — это пакет Python, который позволяет отправлять запросы и обрабатывать ответы от API UDDI версии 2.

UDDI4Py — UDDI4Py — это пакет Python, который позволяет отправлять запросы и обрабатывать ответы от API UDDI версии 2.

UDDI — Технические характеристики

Проект UDDI также определяет набор определений схемы XML, которые описывают форматы данных, используемые различными API-интерфейсами спецификаций. Эти документы доступны для скачивания на сайте www.uddi.org . Текущая версия всех групп спецификаций — Версия 2.0.

Спецификации включают следующее —

• Репликация UDDI,
• Операторы UDDI,
• API программиста UDDI и
• UDDI структуры данных

Репликация UDDI

В этом документе описываются процессы и интерфейсы репликации данных, которым должен соответствовать оператор реестра для обеспечения репликации данных между сайтами. Эта спецификация не является API программиста; он определяет механизм репликации, используемый среди узлов UBR.

UDDI Операторы

Этот документ описывает поведение и рабочие параметры, требуемые операторами узла UDDI. Эта спецификация определяет требования к управлению данными, которым должны следовать операторы.

API программиста UDDI

Эта спецификация определяет набор функций, которые поддерживаются всеми реестрами UDDI для запроса об услугах, размещенных в реестре, и публикации информации о бизнесе или услуге в реестре. Эта спецификация определяет серию сообщений SOAP, содержащих XML-документы, которые реестр UDDI принимает, анализирует и отвечает. Эта спецификация, наряду со схемой UDDI XML API и спецификацией структуры данных UDDI, составляет полный интерфейс программирования для реестра UDDI.

UDDI структуры данных

Эта спецификация охватывает специфику XML-структур, содержащихся в сообщениях SOAP, определенных API-интерфейсом программиста UDDI. Эта спецификация определяет пять основных структур данных и их отношения друг с другом.

Схема UDDI XML API не содержится в спецификации; скорее он хранится в виде документа схемы XML, который определяет структуру и типы данных структур данных UDDI.

UDDI — Резюме

UDDI и его элементы в этом руководстве, а также ознакомились с полной архитектурой и моделью данных UDDI.

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

Что дальше?

Следующим шагом будет изучение SOAP, WSDL и веб-сервисов.

МЫЛО

SOAP — это простой протокол на основе XML, который позволяет приложениям обмениваться информацией по HTTP.

Если вы хотите узнать больше о SOAP, посетите наш учебник по SOAP .

WSDL

WSDL — это стандартный формат для описания веб-службы в формате XML.

WSDL является неотъемлемой частью UDDI.

Если вы хотите узнать больше о WSDL, посетите наш учебник WSDL .

Веб-сервисы

Веб-сервисы могут конвертировать ваши приложения в веб-приложения.

Если вы хотите узнать больше о веб-сервисах, посетите наш учебник по веб-сервисам .

UDDI — API Quick References

Вот полная ссылка на API запросов UDDI и API публикации UDDI.

API запросов UDDI

Имя API	Описание	V1.0	V2.0
find_binding	Поиск привязок шаблона, связанных с указанной службой.	Y	Y
find_business	Ищет бизнес, который соответствует указанным критериям.	Y	Y
find_relatedBusinesses	Обнаруживает бизнес, который был связан через модель отношений uddi-org :.		Y
find_service	Поиск службы, связанной с указанным бизнесом.	Y	Y
find_tModel	Ищет записи tModel, которые соответствуют указанным критериям.	Y	Y
get_bindingDetail	Извлекает полный bindingTemplate для каждого указанного bindingKey.	Y	Y
get_businessDetail	Получает полный businessEntity для каждого указанного businessKey.	Y	Y
get_businessDetailExt	Получает расширенный businessEntity для каждого указанного businessKey.	Y	Y
get_serviceDetail	Извлекает запись businessService для каждого указанного serviceKey.	Y	Y
get_tModelDetail	Извлекает запись tModel для каждого указанного tModelKey.	Y	Y

API публикации UDDI

Имя API	Описание	V1.0	V2.0
get_authToken	Получает токен авторизации. Все операции интерфейса Publisher требуют, чтобы с запросом был представлен действительный токен авторизации.	Y	Y
discard_authToken	Сообщает реестру UDDI больше не принимать данный токен авторизации. Этот шаг эквивалентен выходу из системы.	Y	Y
save_business	Создает или обновляет информацию бизнес-объекта, содержащуюся в реестре UDDI.	Y	Y
save_service	Создает или обновляет информацию о веб-сервисах, которые предоставляет бизнес-объект.	Y	Y
save_binding	Создает или обновляет техническую информацию о реализации веб-службы.	Y	Y
save_tModel	Создает или обновляет регистрацию абстрактных концепций, управляемых реестром UDDI.	Y	Y
delete_business	Полностью удаляет указанные бизнес-объекты из реестра UDDI.	Y	Y
delete_service	Полностью удаляет указанные веб-сервисы из реестра UDDI.	Y	Y
delete_binding	Удаляет технические подробности данного веб-сервиса из реестра UDDI.	Y	Y
delete_tModel	Удаляет указанные tModels из реестра UDDI.	Y	Y
get_registeredInfo	Возвращает сводку всего, что реестр UDDI в данный момент отслеживает для пользователя, включая все предприятия, все службы и все tModels.	Y	Y
set_publisherAssertions	Управляет всеми отслеживаемыми утверждениями отношений, связанными с отдельной учетной записью издателя.		Y
add_publisherAssertions	Вызывает добавление одного или нескольких publisherAssertions в коллекцию утверждений отдельного издателя.		Y
delete_publisherAssertions	Вызывает удаление одного или нескольких элементов publisherAssertion из коллекции утверждений издателя.		Y
get_assertionStatusReport	Предоставляет административную поддержку для определения статуса текущих и невыполненных утверждений издателя, которые включают любую регистрацию бизнеса, управляемую отдельной учетной записью издателя.		Y
get_publisherAssertions	Получает полный набор утверждений издателя, связанных с отдельной учетной записью издателя.		Y

Ссылка на код ошибки

Полная ссылка на коды ошибок, возвращаемые API UDDI, выглядит так:

Коды ошибок