Журнал ВРМ World
Интерпретация UDDI и JAXR
В очередной раз разработчики программного обеспечения оказались поставленными перед дилеммой: какую позицию следует занять в отношении SOAP-служб, ведь пока неясно, смогут ли эти службы поддерживать все более популярное серверное программирование.
Сторонники SOAP-служб полагают, что:
- Корпоративный сервер приложений - это совокупность служб (или транзакций).
- Доступные службы должны быть перечислены для удобства просмотра, поиска и обращения.
- Создание сервера приложений в виде совокупности служб будет способствовать тому, что разработчики станут отдавать предпочтение лучшим методикам проектирования, подобно тому, как сейчас при разработке они используют компонентный подход.
- Эти единицы транзакций можно перемещать, заменять, для них можно выравнивать нагрузку, устанавливать защиту и т. д.
Скептики, с другой стороны, рассматривают SOAP-службы как еще одну попытку расширить аудиторию CORBA и COM. Они отмечают, что SOAP, похоже, требует много усилий даже для простого обращения к объекту, и утверждают, что преимущества UDDI как средства дифференциации/продаж бизнесов преувеличены.
Так какую точку зрения принять? Некоторые разработчики уже примкнули к тому или иному "стану"; тому же, кому хочется сделать выбор самостоятельно: за или против SOAP-служб, следует понять некоторые базовые технологии.
С этой целью я потратил почти неделю, просматривая журналы и интерактивные средства печати, пытаясь найти исчерпывающую информацию о роли и значении UDDI/WSDL для служб. Я надеялся, что, прочитав эту статью, вы будете избавлены от необходимости делать то же, что и я, и сэкономите массу времени. Я не стал бы писать о UDDI, если бы этот стандарт не был бы настолько абстрактным и сложным. Но он именно такой: справедливо и первое, и второе, и это станет очевидным после того, как вы познакомитесь с моими выводами.
Анонсированные ссылки в конце статьи могут служить отправным моментом в освоении базового материала. Я намерен осветить в основном только каверзные моменты, присущие этому стандарту, что же касается общих положений, то я ограничусь лишь кратким изложением основ.
Внутри UDDI
Давайте начнем с разъяснения аббревиатуры. UDDI расшифровывается как Universal Description, Discovery and Integration (Универсальное описание, обнаружение и интеграция). Назначение стандарта - функционировать в качестве регистра, подобно "Желтым страницам", используемым для фиксации бизнесов в определенном районе города. Как и в "Желтых страницах" компании должны регистрировать в UDDI-регистре под различными категориями себя или свои услуги. Тогда, просматривая UDDI-регистр, разработчик может найти услугу или компанию и определить, как вызвать эту услугу.
В отличие от "Желтых страниц" стандарт также ссылается на "Белые" и "Зеленые страницы". "Белые страницы" - это список бизнес сущностей (business entity). "Зеленые страницы" (и здесь метафора с телефонной книгой теряет всякий смысл, если только телефонные компании не припрятывают технические руководства в зеленой обложке) в основном представляют техническую информацию, необходимую для активизации данной услуги.
Определения UDDI настолько общие, что могут включать услуги различного рода, которые необязательно являются SOAP-службами. Определение UDDI могло бы описывать факсимильную или телефонную службу. UDDI, являясь регистром, обычно реализуется с помощью той или иной базы данных. Эта база данных включает модель данных, которая допускает регистрацию и запрашивание элементов информации.
Модель данных UDDI
Модель данных UDDI состоит из следующих основных элементов:
- businessEntity (бизнес-сущность): представляет реальную компанию.
- businessService (сервис информация): представляет услугу, предлагаемую компанией.
- bindingTemplate (связывающий шаблон): инструкции о том, как вызвать услугу.
- tModel (информация о спецификациях для предоставления служб): удачи тому, кто попытается это понять. (Это шутка, объяснение этого элемента будет приведено ниже.)
Примеры XML-документов под UDDI можно посмотреть здесь.
Чтобы основательно разобраться в данной модели данных, давайте посмотрим на UML- представление этих элементов. На рисунке 1 показаны связи между четырьмя основными элементами.
Рис. 1. Связи между businessEntity, businessService, bindingTemplate и tModel
Посмотрев на этот рисунок, можно понять, что в бизнес-сущность (компанию) входит описательный URL, который рассказывает о компании, и ее контактная информация. Помимо этого, бизнес-сущность содержит список бизнес-служб. Существует множество способов вызвать эти услуги. Каждый вызов описывается при помощи связывающего шаблона. Для того, чтобы связывающий шаблон детально определял, как обратиться к службе, необходим ряд документов, описывающих как можно получить доступ к этой службе. Связь между связывающим шаблоном и этой обязательной документацией осуществляется через так называемый элемент tModel. На приведенном выше рисунке эта связь упрощенно представлена в виде связывающего шаблона (bindingTemplate) с набором элементов tModel. Далее я подробно рассмотрю этот момент. К сожалению, прежде чем объяснить, как элементы tModel относятся к связывающим шаблонам, необходимо сначала понять, что такое tModel.
Что такое tModel?
Представьте себе tModel как независимую таблицу базы данных со следующими столбцами: имя, описание, URL (который может предоставить более подробные сведения об имени и описании) и уникальный ключ (для идентификации имени). В сущности, tModel - это нечто, что имеет "имя" и "описание". Какая же может быть польза от столь ничтожной информации? Не излишество ли это - использовать таблицу базы данных для представления столь незначительной идеи? Давайте выясним это на примере.
Вот пара записей в воображаемой базе данных tModel:
| Ключ | Имя | Описание | URL |
| 1 | Java-class | Представляет полностью квалифицированное имя класса java | http://www.javasoft.com |
| 2 | Java-class | Представляет имя JNDI. Смотрите приложение J2EE | http://www.javasoft.com |
Соотнеся tModel с таблицей базы данных, можно заметить несколько важных моментов. Прежде всего, tModel - это независимая таблица, что означает, что она может существовать сама по себе. Во-вторых, tModel является справочной таблицей (lookup table), обеспечивающей преобразование между ключом и представлением того, что есть этот ключ. В этом смысле tModel - это таблица ссылок (reference table), подобная словарю. В некоторых базах данных такая таблица известна как codeset.
Во всех случаях указанные выше описания позволят мне сказать:
com.mycompany.HelloWorld, 1
Что означает, что com.mycompany.HelloWorld является полностью
квалифицированным классом Java.
com.mycompany.HelloWorldHome, 2
означает, что com.mycompany.HelloWorldHome - имя JNDI. Что, в
определенном смысле, представляет понятие, а именно "пространство имен". Чтобы
пояснить это, рассмотрим следующий пример:
904-555-1212
904-555-1213
1-56592-391-x
Как можно определить, что это за цифры? Требуется контекст, или пространство имен, чтобы установить, что 904-555-1212 - это телефонный номер, 904-555-1213 - номер факса, а 1-56592-391-x - ISBN (Международный стандартный номер книги).
Поэтому, в своей базе данных tModel вы определите три записи: одну для телефонного номера, другую для номера факса, и третью для ISBN.
Давайте предположим, что ваша компания "mycompany" установила линию поддержки под номером "1-800-my-helpline", и вы хотите зарегистрировать ее с помощью UDDI. Тогда ваши модели данных будут выглядеть следующим образом:
company name: mycompany
Service name: helpline
tModel: key=11 (representing telephoneline), name=telephone,
description=telephone stuff, url:
some at&t url
binding:
accesspoint: 1-800-my-helpline
tModelInstanceInfo: 11
После того, как мы разобрались, что такое tModel, давайте,
используя UML-схему, изучим связь между связывающим шаблоном и элементами
tModel. Как я упоминал ранее, тогда мы сможем понять, каким образом
связывающий шаблон выполняет требование UDDI: "как вызвать службу".
Рис. 2. Связи между bindingTemplate и элементами
tModel
На рисунке 2 показаны связи между связывающим шаблоном и элементами tModel. Из рисунка видно, что связывающий шаблон указывает на техническую спецификацию, идентифицированную посредством tModel. Эта спецификация состоит из двух частей:
- Тип спецификации (например, адрес электронной почты, факс, WSDL, SOAP-служба и т. д.).
- Документы, указывающие входные и выходные данные (в случае SOAP-службы такими документами могли бы быть входные/выходные форматы XML-сообщений).
После того, как я подробно осветил элементы tModel, мы можем перейти к следующему уровню сложности - а именно к "идентификационным" и "категориальным сумкам" (identity bags, category bags).
Объяснение "идентификационных" и "категориальных сумок"
Если освоение концепции элементов tModel является первым условием понимания UDDI, то осознание сути "идентификационных" и "категориальных сумок" - вторым. Объяснить смысл этих "сумок" лучше всего на примере.
Предположим, что компания занимается бизнесом в США под некоторым идентификационным налоговым номером (tax ID number). Для того, чтобы развернуть деятельность в другой стране (например, Мексике), вам пришлось бы также располагать идентификационным налоговым номером для Мексики. Чтобы заполучить информацию о вашей компании в UDDI-регистре, потребовалось бы сделать следующее:
Company name: mycompany
Identifiers:
US tax number: 111111
Mexico tax number: 2223344
Some other number: 333333
...Other xml stuff
<identifierBag>
<keyedReference tModelKey="US-tax-code"
keyName="taxnumber" keyValue="1111111">
<keyedReference tModelKey="Mexico-tax-code"
keyName="taxnumber" keyValue="2223344">
<keyedReference tModelKey="other-stuff"
keyName="taxnumber" keyValue="333333">
</identifiedBag>
... Other xml
Из примера видно, что элементы tModel используются в качестве пространств имен (us-tax-code, mexico-tax-code и т. д.) UML-схема на рисунке 3 развивает концепцию "идентификационных сумок".
Рис.3. Объяснение "идентификационных" и "категориальных сумок"
Из рисунка 3 следует, что "идентификационная сумка" - это набор пар ключ/значение в пределах данного контекста. Этот контекст -по существу пространство имен, которое может однозначно разрешить эти пары ключ/значение. Это пространство имен идентифицировано посредством tModel. То же самое справедливо и в отношении "категориальных сумок". Единственное различие заключается в том, что пространство имен, установленное посредством tModel в "категориальной сумке", указывает на предопределенную категорию (или "таксономию").
"Категориальные сумки"
Давайте предположим, что я хочу, чтобы моя компания относилась к категории "restaurant" (ресторан) и географически числилась в Джэксонвилле ("Jacksonville").
Company name: mycompany
Applicable Categories:
Type of business classification: restaurant
city classification: Jacksonville
<categoryBag>
<keyedReference tModelKey="BusinessTypeClassification"
keyName="restaurant" keyValue="..">
<keyedReference tModelKey="CityClassification"
keyName="JAX" keyValue="..">
</categoryBag>
Мы рассмотрели, как элементы tModel используются для целей "идентификационных" и "категориальных сумок". По существу элементы tModel служили в качестве пространств имен.
Существуют ли какие-нибудь стандартные пространства имен и/или классификации, которые предоставляются любым UDDI-поставщиком?
| Таксономия | tModelName |
| NAICS | ntis-gov:naics:1997 |
| ISO 3166 | iso-ch:3166:1999 |
| UNSPSC | unspsc-org:unspsc:3-1 |
| Другая таксономия | uddi-org:general_keywords |
Очевидно, что вам потребуется получить уникальные ключи этих элементов tModel, чтобы сослаться на них в своих "категориальных сумках".
Лучший источник информации, необходимой для понимания "идентификационных" и "категориальных сумок" - файл (PDF) "Структуры UDDI-данных", находящийся на UDDI.org.
Можно ли также устанавливать категории элементов tModel?
Мы рассмотрели, как с помощью элементов tModel бизнес-сущность может использовать "категориальные сумки". Помимо этого, UDDI позволяет устанавливать категории самих элементов tModel. А зачем?
Давайте проведем параллель с иерархией файловой системы: каталоги используются для размещения файлов по категориям, но сами каталоги также могут быть распределены по вышестоящим директориям. Элементы tModel могут быть организованы иерархически, подобно каталогам, хранящим файлы на жестком диске.
Представим службу, getUniversalTime(), которая для любой точки земного шара возвращает текущее время по Гринвичу. При этом, эту услугу предоставляют две конкурирующие фирмы. Бизнес-служба привязана к компании и невидима вне нее. Таким образом, вы получите следующее:
company1:getTime()
company1:getCurrentTime()
Каждая из них делает то же самое. Чтобы показать, что они реализуют конкретную концептуальную службу, getUniversalTime(), вы можете определить следующий элемент tModel:
tModel
name: Get Universal Time
category: uddi-org:types, wsdl
[implying that this a service
as
described by a WSDL
document]
Данное определение означает, что getUniversalTime() является службой WSDL и может быть выполнено любой организацией.
После того, как я разъяснил связь между элементами tModel и "сумками", можно привести UML-схему tModel.
Рис. 4. Объяснение tModel с помощью UML-схемы
Из рисунка видно, что tModel, по существу, это имя и описание. Кроме того, для дальнейшей детализации этот элемент может содержать URL. Наконец, элемент tModel может быть идентифицирован при помощи "идентификационной сумки"" и отнесен к категориям посредством "категориальной сумки".
Сколько других типов содержится в категории uddi-org:types?
Рассматривая процесс установления категорий tModel, мы также узнали, что некоторые категории, к которым может принадлежать tModel, предопределенны стандартом UDDI - WSDL, SOAP-службы и т.д. Ниже приведен список этих предопределенных категорий в пространстве имен uddi-org:types.
- tModel,
- identifier (уникальный идентификатор),
- namespace,
- categorization,
- specification,
- xmlSpec,
- soapSpec,
- wsdlSpec,
- protocol,
- protocol,
- signatureComponent.
Так как же создать службу в UDDI?
- Начните с определения tModel для своей службы. Для этого требуется имя этой службы и один из приведенных выше типов служб. Разумеется, вы также можете создать свои собственные категории, если вам не особенно нравятся предложенные варианты.
- Определите бизнес-службу под вашей компанией, указав на элемент tModel, который вы создали.
- При описании этой бизнес-службы вам потребуется установить URL, указывающий на действительный WSDL-документ, который определяет входные/выходные данные вашей службы (при условии, что вы используете WSDL-совместимую службу).
В статье Энди Гроува (Andy Grove), опубликованной в ноябрьском номере Web Services Journal (2001 год), с помощью примера показано, как это можно сделать.
Для чего элементы tModel используются в UDDI?
Элементы tModel используются в UDDI для следующих целей:
- Идентификации бизнес-сущностей и распределения их по категориям.
- Идентификации бизнес-служб и распределения их по категориям.
- Идентификации элементов tModel и распределения их по категориям.
- Совмещения/связывания бизнес-служб с их абстрактными описаниями tModel.
Краткий справочник по терминологии UDDI
При чтении литературы по UDDI невольно сталкиваешься с довольно абстрактными терминами, что не может не вызвать раздражения. А авторы еще пытаются сопоставлять понятия UDDI с другими аспектами IT-технологий. Тем не менее, при освоении общих положений UDDI очень полезно проводить такие параллели (даже отдаленные).
Интерфейсы и реализации
Под связыванием службы понимают случай, при котором интерфейсы связаны со своими реализациями; связующий элемент устанавливает и tModelInstaceInfo, и instanceDetail. TModelInstaceInfo указывает на элемент tModel, который действительно определяет имя службы. Предполагается, что instanceDetail предоставляет некоторые специфические детали об этой службе.
И нам снова не обойтись без примера. Для службы "Get Universal Time" ("Получи время по Гринвичу") такая деталь должна обеспечивать действительный WSDL-документ, который определяет входные и выходные данные. Вдобавок, элемент связывания accesspoint передаст вам физическую машину или порт, где эта служба реализована. С учетом сказанного, можно сделать следующие выводы:
- Элемент tModel, определенный для службы является интерфейсом, позволяющим многим компаниям обеспечивать многочисленные реализации.
- Связывание службы является реализацией.
Пространства имен
Пространства имен присутствуют во всех языках программирования: Java, C++ и XML. Возможно, под ними подразумеваются разные понятия, но все они предоставляют контекст, под которым имя имеет смысл. В UDDI tModel представляет "имя". Когда вы ссылаетесь на это имя как на свою категорию, вы по существу говорите: "Я отношусь к этому имени". В этом смысле tModel представляет пространство имен.
Характерные технические признаки
Когда служба регистрируется как tModel, можно зарегистрировать протокол, который используется для связи с этой службой (например, WSDL, SOAP и т. д.). В результате, tModel обладает характерным признаком WSDL или SOAP - в зависимости от того, какая спецификация используется. Таким образом, элементы tModel считаются техническими характеристиками, причем каждый из них отвечает определенным техническим спецификациям. Поскольку tModel может представлять "технический признак", то я бы поддержал утверждение о том, что tModel представляет также и "протокол".
Таксономия
Таксономия является синонимом (и эквивалентом) распределению по категориям, классификации и пространствам имен. Таксономия обеспечивает контекст, при котором такие идентификаторы, как числа и имена, имеют смысл. Например, налоги США и ISBN имеют смысл только тогда, когда они являются налоговыми номерами, относящимися к США, или международными стандартными номерами книги. Этот вид классификации иногда называется таксономией.
"Белые страницы"
Список бизнес-сущностей в UDDI-регистре и возможность искать компании, основываясь на их имени.
"Желтые страницы"
Они распределяют бизнес-сущности по их бизнес-категориям и другим разновидностям категорий.
"Зеленые страницы"
Определение службы и требования, предъявляемые к процедуре доступа к ней, становятся более понятными при использовании ряда документов. Особая роль в этом случае принадлежит serviceBindings и tModel.
Примеры XML для UDDI
Я не мог не упомянуть о следующих отличных примерах XML-документов для UDDI, которые помогут вам закрепить "пройденный материал".
- Во-первых, это великолепная статья Энди Гроува (Andy Grove), о которой уже шла речь, опубликованная в ноябрьском номере Web Services Journal (2001 год): "Толкование элементов tModel UDDI и таксономий" ("Understanding UDDI tModels and Taxonomies").
- Второй пример доступен по следующей ссылке:
http://dcb.sun.com/practices/webservices/overviews/overview_uddi.jsp.
"Рекомендуемая литература"
- Энди Гроув (Andy Grove) "Толкование элементов tModel UDDI и
таксономий" ("Understanding UDDI tModels and Taxonomies"), Web Services
Journal, ноябрь 2001.
Если у вас имеется этот журнал, то я советую вам сначала познакомиться с самой концепцией UDDI и tModel. А затем изучить модель данных, которая освещена на сайте uddi.org. Кроме того, это хороший пример XML-документа для UDDI. - Спецификация структуры данных UDDI (pdf).
Это наиболее подробный и значимый документ о стандарте, необходимый для понимания UDDI. Если вы хотите ограничиться только одним источником, то это - как раз тот самый документ. - UML-схема UDDI
Совсем недавно DTD для XML представлялся с помощью UML. Ведь поскольку этот язык опирается на графические изображения, он легко может передать структуру XML-документа. Этот документ с XMLModelling.com "берет на вооружение" преимущества этого подхода и является подробнейшим XML-представлением UDDI. Единственный недостаток - излишняя детализация, которая может утомить читателя. - UDDI корпорации Microsoft
Посетив Web-сайт Microsoft вы сможете понять UDDI-регистр с позиции графического интерфейса пользователя. Например, как можно графически зарегистрировать службу и как можно искать службы в Интернете.
Данный документ рассказывает об основных структурах UDDI и о том, как можно программно и интерактивно манипулировать ими. - UDDI-документы компании IBM
По данному URL можно найти объяснение отношения WSDL и UDDI.