В очередной раз разработчики программного обеспечения оказались поставленными перед дилеммой: какую позицию следует занять в отношении SOAP-служб, ведь пока неясно, смогут ли эти службы поддерживать все более популярное серверное программирование.
Сторонники SOAP-служб полагают, что:
Скептики, с другой стороны, рассматривают SOAP-службы как еще одну попытку расширить аудиторию CORBA и COM. Они отмечают, что SOAP, похоже, требует много усилий даже для простого обращения к объекту, и утверждают, что преимущества UDDI как средства дифференциации/продаж бизнесов преувеличены.
Так какую точку зрения принять? Некоторые разработчики уже примкнули к тому или иному "стану"; тому же, кому хочется сделать выбор самостоятельно: за или против SOAP-служб, следует понять некоторые базовые технологии.
С этой целью я потратил почти неделю, просматривая журналы и интерактивные средства печати, пытаясь найти исчерпывающую информацию о роли и значении UDDI/WSDL для служб. Я надеялся, что, прочитав эту статью, вы будете избавлены от необходимости делать то же, что и я, и сэкономите массу времени. Я не стал бы писать о UDDI, если бы этот стандарт не был бы настолько абстрактным и сложным. Но он именно такой: справедливо и первое, и второе, и это станет очевидным после того, как вы познакомитесь с моими выводами.
Анонсированные ссылки в конце статьи могут служить отправным моментом в освоении базового материала. Я намерен осветить в основном только каверзные моменты, присущие этому стандарту, что же касается общих положений, то я ограничусь лишь кратким изложением основ.
Давайте начнем с разъяснения аббревиатуры. UDDI расшифровывается как Universal Description, Discovery and Integration (Универсальное описание, обнаружение и интеграция). Назначение стандарта - функционировать в качестве регистра, подобно "Желтым страницам", используемым для фиксации бизнесов в определенном районе города. Как и в "Желтых страницах" компании должны регистрировать в UDDI-регистре под различными категориями себя или свои услуги. Тогда, просматривая UDDI-регистр, разработчик может найти услугу или компанию и определить, как вызвать эту услугу.
В отличие от "Желтых страниц" стандарт также ссылается на "Белые" и "Зеленые страницы". "Белые страницы" - это список бизнес сущностей (business entity). "Зеленые страницы" (и здесь метафора с телефонной книгой теряет всякий смысл, если только телефонные компании не припрятывают технические руководства в зеленой обложке) в основном представляют техническую информацию, необходимую для активизации данной услуги.
Определения UDDI настолько общие, что могут включать услуги различного рода, которые необязательно являются SOAP-службами. Определение UDDI могло бы описывать факсимильную или телефонную службу. UDDI, являясь регистром, обычно реализуется с помощью той или иной базы данных. Эта база данных включает модель данных, которая допускает регистрацию и запрашивание элементов информации.
Модель данных UDDI состоит из следующих основных элементов:
Примеры XML-документов под UDDI можно посмотреть здесь.
Чтобы основательно разобраться в данной модели данных, давайте посмотрим на UML- представление этих элементов. На рисунке 1 показаны связи между четырьмя основными элементами.
Рис. 1. Связи между businessEntity, businessService, bindingTemplate и tModel
Посмотрев на этот рисунок, можно понять, что в бизнес-сущность (компанию) входит описательный URL, который рассказывает о компании, и ее контактная информация. Помимо этого, бизнес-сущность содержит список бизнес-служб. Существует множество способов вызвать эти услуги. Каждый вызов описывается при помощи связывающего шаблона. Для того, чтобы связывающий шаблон детально определял, как обратиться к службе, необходим ряд документов, описывающих как можно получить доступ к этой службе. Связь между связывающим шаблоном и этой обязательной документацией осуществляется через так называемый элемент tModel. На приведенном выше рисунке эта связь упрощенно представлена в виде связывающего шаблона (bindingTemplate) с набором элементов 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. Эта спецификация состоит из двух частей:
После того, как я подробно осветил элементы 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 служили в качестве пространств имен.
Таксономия | 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 бизнес-сущность может использовать "категориальные сумки". Помимо этого, 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 может быть идентифицирован при помощи "идентификационной сумки"" и отнесен к категориям посредством "категориальной сумки".
Рассматривая процесс установления категорий tModel, мы также узнали, что некоторые категории, к которым может принадлежать tModel, предопределенны стандартом UDDI - WSDL, SOAP-службы и т.д. Ниже приведен список этих предопределенных категорий в пространстве имен uddi-org:types.
В статье Энди Гроува (Andy Grove), опубликованной в ноябрьском номере Web Services Journal (2001 год), с помощью примера показано, как это можно сделать.
Элементы tModel используются в UDDI для следующих целей:
При чтении литературы по UDDI невольно сталкиваешься с довольно абстрактными терминами, что не может не вызвать раздражения. А авторы еще пытаются сопоставлять понятия UDDI с другими аспектами IT-технологий. Тем не менее, при освоении общих положений UDDI очень полезно проводить такие параллели (даже отдаленные).
Под связыванием службы понимают случай, при котором интерфейсы связаны со своими реализациями; связующий элемент устанавливает и tModelInstaceInfo, и instanceDetail. TModelInstaceInfo указывает на элемент tModel, который действительно определяет имя службы. Предполагается, что instanceDetail предоставляет некоторые специфические детали об этой службе.
И нам снова не обойтись без примера. Для службы "Get Universal Time" ("Получи время по Гринвичу") такая деталь должна обеспечивать действительный WSDL-документ, который определяет входные и выходные данные. Вдобавок, элемент связывания accesspoint передаст вам физическую машину или порт, где эта служба реализована. С учетом сказанного, можно сделать следующие выводы:
Пространства имен присутствуют во всех языках программирования: Java, C++ и XML. Возможно, под ними подразумеваются разные понятия, но все они предоставляют контекст, под которым имя имеет смысл. В UDDI tModel представляет "имя". Когда вы ссылаетесь на это имя как на свою категорию, вы по существу говорите: "Я отношусь к этому имени". В этом смысле tModel представляет пространство имен.
Когда служба регистрируется как tModel, можно зарегистрировать протокол, который используется для связи с этой службой (например, WSDL, SOAP и т. д.). В результате, tModel обладает характерным признаком WSDL или SOAP - в зависимости от того, какая спецификация используется. Таким образом, элементы tModel считаются техническими характеристиками, причем каждый из них отвечает определенным техническим спецификациям. Поскольку tModel может представлять "технический признак", то я бы поддержал утверждение о том, что tModel представляет также и "протокол".
Таксономия является синонимом (и эквивалентом) распределению по категориям, классификации и пространствам имен. Таксономия обеспечивает контекст, при котором такие идентификаторы, как числа и имена, имеют смысл. Например, налоги США и ISBN имеют смысл только тогда, когда они являются налоговыми номерами, относящимися к США, или международными стандартными номерами книги. Этот вид классификации иногда называется таксономией.
Список бизнес-сущностей в UDDI-регистре и возможность искать компании, основываясь на их имени.
Они распределяют бизнес-сущности по их бизнес-категориям и другим разновидностям категорий.
Определение службы и требования, предъявляемые к процедуре доступа к ней, становятся более понятными при использовании ряда документов. Особая роль в этом случае принадлежит serviceBindings и tModel.
Я не мог не упомянуть о следующих отличных примерах XML-документов для UDDI, которые помогут вам закрепить "пройденный материал".