Главная » Java, Web, XML » Состав реестра UDDI

0

Реестр UDDI разбивает хранящуюся в нем информацию на несколько групп.

Четыре основные группы состоят из следующих отдельных документов или частей одного документа.

•          Бизнес-информация — документ с корневым элементом <businessEntity> — описание фирмы-поставщика Web-услуг: ее ключ UUID (Unique Universal Identifier), уникальный в пределах реестра и описанный атрибутом businessKey, название фирмы — вложенный элемент <name>, краткое описание сферы ее деятельности, типы предоставляемых услуг, контактная информация, ссылки URL. Эта информация предназначена для всех, кто хочет воспользоваться услугами фирмы.

?         Бизнес-услуги — элемент <businessServices>, вложенный в элемент <businessEntity> – список услуг, оказываемых фирмой. Каждая услуга описывается вложенным элементом <businessservice>. В описание входит КЛКН UUID К?ВДМ УСЛУГИ, ОПИСаННЫЙ атрибутом serviceKey, имя услуги — вложенный элемент                                ее краткое описание и ссылки на

на подробную информацию. Услуги могут быть любыми, не обязательно Web-услугами.

?         Указатели на услуги — элемент <bindingTemplates>, вложенный в элемент <businessservice> — способы получения каждой услуги. Они могут быть прямыми, например, URL-адрес Web-службы, или косвенными, например, описание WSDL или IDL. Каждый способ получения услуги описывается одним вложенным элементом <bindingTemplate>. Его атрибут bindingKey определяет уникальный ключ UUID указателя. Элемент      содержит ссылку на соответствующий элемент <tModel>.

?         Модель услуги — элемент <tModel> (technical Model) — подробное формальное описание каждой услуги. Оно используется программным обеспечением узла. Обычно это отдельный документ XML.

В реестре есть еще несколько дополнительных элементов.

?         Утверждение — элемент <publisherAssertion> — описание установленных ранее отношений между фирмами (утверждение "peer-peer") или фирмой и ее подразделениями (утверждение "parent-child"). Фирма утверждает, что она тесно связана с перечисляемыми фирмами или что это — ее подразделения. Третий вид утверждения — "identity" — отношение между одинаковыми фирмами — это фактически псевдоним. Описание утверждения выполняется вложенными элементами <fromKey> и <toKey>, а вид отношения описывается вложенным элементом <keyedReference>. Отношение входит в силу, когда его утвердят оба участника. Это отдельный документ, использующий элементы <businessEntity> обеих фирм.

?         Информация — элемент <operationalinfo> — дата создания и последней модификации записи в реестре, идентификатор узла реестра, идентификатор владельца информации.

? Подписка — элемент <subsc-ription> — список фирм и сведений, которые надо послать перечисленным фирмам при каких-либо изменениях в деятельности фирмы.

Эти элементы определены в пространстве имен UDDI. Идентификатор пространства имен UDDI версии 3.0 равен "urn:uddi-org:api_v3".

Уникальный ключ UUID, встречающийся в этих элементах, имеет примерно такой вид: "uddi:example.com: 1" или "uddi:example.com:sales-division:53". Устаревшая форма записи UUID выглядит примерно так: "4CD7E4BC- 648B-426D-9936-443EAAC8AE23".

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

?         символ [?] означает, что элемент или атрибут может появиться в документе нуль или один раз;

?         символ [*] означает, что элемент может появиться нуль или несколько раз;

?         символ [+] означает, что элемент может появиться один или несколько раз;

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

Листинг 5.1. Основные элементы UDDI-описания бизнес-информации

<businessEntity businessKey="iaro4 UUID" [?] > <name 1апд="язык" [?] >имя</пате> [+] <buslnessServices> [?]

<businessService serviceKey="Kmo4 UUID" [?] > [+] <bindingTemplates> [?]

<bindingTemplate bindingKey="Kjiio4 UUID" [?] > [+]

<!— Описание указателя — > </bindingTemplate>

< /bindingTemplates> </businessService> < /businessServices> < /businessEntity>

Рассмотрим подробнее каждый элемент. У элементов <businessServices> и <bindingTemplates> нет атрибутов, они содержат только один или несколько вложенных элементов <businessService> ИЛИ <bindingTemplate> соответственно.

Структура остальных элементов сложнее. Мы рассмотрим их в следующих разделах.

Элемент <businessEntity>

У элемента <businessEntity> есть один необязательный атрибут businessKey, уже показанный в листинге 5.1. Этот атрибут определяет уникальный ключ UUID бизнес-информации. Если он отсутствует, то ключ  генерируется реестром UDDI.

В элемент                                   вкладывается восемь элементов, из них обяза

телен только один элемент                   Ниже перечислены эти элементы.

?         Элемент <discoveryURLs> содержит один или несколько вложенных элементов  содержащих ссылки на файлы, в которых расположено описание бизнес-информации.

Элементы                  которые могут встретиться несколько раз, содержат

названия фирмы в полном и сокращенном виде на разных языках.

?         Элемент <description>, содержащий произвольное описание бизнес- информации, тоже может встретиться несколько раз, например, на разных языках.

?         Элемент <contacts> содержит один или несколько вложенных элементов <contact>, содержащих, в свою очередь, несколько вложенных элементов, описывающих контактную информацию:

?         нуль или несколько элементов <description> с произвольным описанием контактной информации на разных языках;

?         один или несколько элементов <personName> с именами или должностями партнеров;

?         нуль или несколько элементов <phone> с номерами контактных телефонов;

?         нуль или несколько элементов <email> с адресами электронной почты;

?         нуль или несколько элементов <address>, содержащих почтовые адреса фирмы.

?         Уже ОПИСиНЫЙ Элемент<businessService>.

?         Элемент <identifierBag> содержит идентификаторы бизнес- информации в различных системах идентификации или классификации. Они записываются в атрибутах одного или нескольких вложенных элементов <keyedReference>. У этих элементов два обязательных атрибута:

содержащий ключ                                   элемента                    описывающего

систему идентификации, и keyvalue со значением идентификатора. Необязательный атрибут keyName содержит произвольное краткое имя идентификатора. Это имя должно быть уникальным в пределах данной

системы идентификации. Таким образом, значение атрибута tModelKey работает аналогично идентификатору пространства имен, обеспечивая уникальность имени.

? Элемент <categoryBag> тоже содержит один или несколько элементов <keyedReference>, описывающих некоторые категории бизнеса, например, его разделение по географическим районам. Он может содержать НУЛЬ ИЛИ Несколько элементов <keyedReferenceGroup> С атрибутом tModeiKey И ВЛОЖеННЫМИ элементами <keyedReference>. В ОДНу Группу собирается неделимая информация, например, долгота и широта географического пункта. В отличие от элемента <identifierBag>, элемент <categoryBag> относит имена keyName не к определенной системе идентификации, а к некоторой категории, например, виду продукции, определяемому атрибутом tModeiKey.

? Бизнес-информация может быть подписана цифровыми подписями, расположенными В элементах <Signature>.

Как видите, элемент <businessEntity> содержит обширную и всестороннюю информацию о зарегистрированной в реестре UDDI фирме. В листинге 5.2 приведен пример такой информации.

Мистинг 5.2. Пример бизнес-информации

<businessEntity

businessKey="677cfala-2717-462 0-be3 9-6631bb74b6el"> <discoveryORLs>

<discoveryURL useType="businessEntity"> http://uddi.hp.com/discovery?

4;>businessKey=677cfala-2717-4 62 0-be3 9-6 631bb74b6el

</discoveryURL> </discoveryURLs>

<name xml: lang="en">Weather Service</name> <description xml:lang="RU-ru">

Интерактивная метеослужба предоставляет прогноз погоды

на завтра в указанном населенном пункте. </description> <contacts>

<contact useType="Technical support">

<description xml:lang="RU-ru">

Контактная информация метеослужбы. </description>

<personName>onepaTop И. П. Сидоров</регзопЫате>

<phone>234-45-67</phone> <phone>234-45-38</phone> <email>sidor@some.com</email>

<address>318123 Жилки, Ягодная, 23-6</address>

</contact>

</contacts>

<businessServices>

< ! — Сюда вкладываются описания бизнес-услуг. —>

</businessServices>

<identifierBag>

<keyedReference

tModelKey="uddi:ubr.uddi.org:identifier:dnb.com:D-U-N-S"

keyName="HP"

/>

</identifierBag> <categoryBag>

<keyedReference

tModelKey="uddi:c0b9fel3-179f-413d-8a5b-5004db8e5bb2" keyValue="61" />

<keyedReference

tModelKey="uuid:C0b9fel3-179f-413d-8a5b-5004db8e5bb2" keyValue="51419" />

</categoryBag>

</businessEntity>

Элемент <businessService>

У элемента <businessService>, описывающего отдельную бизнес-услугу, два необязательных атрибута serviceKey И businessKey.

Атрибут serviceKey содержит уникальный ключ UUID описываемой услуги. Если он отсутствует, то ключ будет сгенерирован реестром UDDI.

Атрибут businessKey содержит ключ UUID соответствующего элемента <businessEntity>. Его МЖЮ не писать, если элемент <businessService> ЯВНО МОЖеН В Элемент <businessEntity>.

В элемент <businessService> можно вложить пять необязательных элементов. Это имя, записанное в элементе <name>, описание, сделанное в элементе <description>, уже описанный элемент <bindingTemplates> И уже зна- КОМЬЬ нам элементы <categoryBag> И <Signature>.

В листинге 5.3 приведен пример описания бизнес-услуги.

Листинг 5.3. Пример описания бизнес-услуги

cbusinessService

serviceKey="d80 91de4-0a4a-40 61-997 9-5dl9131aece5" businessKey="677cfala-2 717-4 62 0-be3 9-6 631bb74b6el">

<name xml:lang="en">Meteo Service</name>

<description

Прогноз погоды на завтра.

</description>

<bindingTemplates>

< ! — Сюда вкладываются описания указателей. —> </bindingTemplates> </businessService>

Элемент <bindingTemplate>

В открывающем теге элемента                                    описывающего сетевой

адрес и другие способы получения услуги, два необязательных атрибута bindingKey И serviceKey.

Атрибут bindingKey содержит уникальный ключ UUID элемента. Если этот атрибут отсутствует, то его значение генерируется реестром UDDI.

Атрибут serviceKey содержит КПКН UUID элемента <businessService>, В котором он содержится.

В элемент                                вкладывается нуль или несколько описаний

<description> на разных языках и ровно один обязательный элемент <accessPoint>, содержащий адрес описываемой Web-службы, обычно в виде строки URL или электронной почты. В прежних версиях UDDI вместо него использовался элемент <hostingRedirector>, который оставлен в версии UDDI 3.0 для совместимости со старыми версиями.

Кроме того, в элемент <bindingTemplate> можно вложить один из трех необязательных элементов. Два из них — уже знакомые нам элементы <categoryBag> И <Signature>.

Третий элемент <tModellnstanceDetails> содержит один или несколько вложенных элементов ссылающихся на соответст

вующее описание              обязательным атрибутом                      Кроме того,

В элемент <tModelinstanceinfo> МОЖНО ВЛОЖИТЬ описания <description> И дополнительные сведения <instanceDetails>. Элемент <instanceDetails>, в свою очередь, содержит или элементы <overviewDoc>, содержащие ссылки на дополнительные описания в виде URL, или элемент содержащий дополнительные параметры.

В листинге 5.4 приведен пример описания способов получения услуги.

л1исшш „5.4. Пример описания. IDDI способов шчучсния усти

<bindingTemplate

bindingKey="942595d7-0311-4 8b7-9c65-995748a3a8af"

serviceKey="d8091de4-Oa4a-4 061-997 9-5dl9131aece5"> <accessPoint URLType="http">

http: //scne.ccm/services/MeteoService </accessPoint> <tMcclelInlstancёDetails> <tModelIns tancelnfo

tModelKey="uddi:42fab02f-300a-4315-aa4a-f97242ff6953"> <instanceDetails> <overviewDoc> <overviewURL>

http://some.com/services/MeteoService7WSDL </overviewURL> </overviewDoc> </instanceDetails> </tModelInstanceInfo> </tModelInstanceDetails> </binclingIfenplate>

Элемент <tModel>

Открывающий тег элемента <tModei>, описывающего технические детали представления бизнес-услуги, может содержать два необязательных атрибута: tModelKey, содержащий уникальный ключ UUID, и deleted, принимающий значения "true" (по умолчанию), или "false", говорящее о том,

что описание логически удалено. Отсутствие атрибута tModeiKey означает, что ключ UUID будет сгенерирован реестром UDDI.

В элемент <tModel> вкладывается один обязательный элемент <name> — имя описания в виде строки URI — и пять необязательных элементов: <description>, <overviewDoc>, <identifierBag>, <categoryBag> И <signature>. Их содержание и смысл описаны выше. В листинге 5.5 приведен пример описания технических деталей.

………….. – ? ? • ? ……………………………  .

Листинг 5.5. Описание UDDI технических деталей

<tModel

tMode1Кеу="uddi:42fab02f-300a-4315-aa4a-f97242ff6953">

<name>Meteo Service Interface</name> <description xml:lang="RU-ru">

Интерфейс метеослужбы. </description> <overviewDoc>

<description xml:lang="RU-ru"> Описание WSDL метеослужбы. </descript ion> <overviewURL>

http://some.com/services/ifaces/meteoservice.wsdl </overviewURL> </overviewDoc> <categoryBag>

<keyedReference

tModelKey="uddi:clacf26d-9672-4404-9d70-39b756e62ab4" keyValue="wsdlSpec" />

< keyedReference

tModelKey="uddi:c0b9fel3-179f-413d-8a5b-5004db8e5bb2" keyValue="514191" />

</categoryBag> </tModel>

Элемент <publisherAssertion>

Элемент <publisherAssertion>, описывающий связи между фирмами, устроен проще всего. В него ровно один раз вкладываются три элемента <fromKey>, <toKey> и <keyedReference> и может присутствовать одна или несколько цифровых подписей, занесенных в элементы <signature>.

Элемент <keyedReference> уже встречался выше. Его атрибут tModelKey содержит ссылку на полное описание связи между фирмами.

Элементы                 и <toKey> просто содержат ключи UUID связанных

между собой фирм, как показано в листинге 5.6.

‘ Листинг 5.6. Описания связи между фирмами

<publisherAssert ion>

<fromKey>677cfala-2717-4620-be39-6631bb74b6el</fгошКеу>

<toKey>677cfala-2717-4620-be27-6631bb45b3 4</toKey>

<keyedReference

tModelKey=’uddi:807a2c6a-ee22-470d-adc7-e0424a337c03′ keyValue=’peer-peer’/>

</publisherAssert ion>

Литература:

Хабибуллин И. Ш. Разработка Web-служб средствами Java. — СПб.: БХВ-Петербург, 2003. — 400 с: ил.

По теме:

  • Комментарии