- 30 мая 2001 г.
Назначение частных UDDI-узлов в Web-службах. Часть 1: шесть типов UDDI
Во второй статье рубрики рассматриваются шесть типов стандарта UDDI. и рекомендации по их использованию.
В сервис-ориентированной архитектуре описания служб, а также метаданные, играют центральную роль в поддержании свободного соединении между теми, кто обращается к службам, и теми, кто их предоставляет: эти описания, публикуемые поставщиками служб, позволяют запросчикам связываться с поставщиками. Методы доставки информации о службах достаточно разработаны: можно попросить "отправить описания службы по электронной почте" или же просто перенести файлы с описанием на физическом носителе (sneaker net), наконец, можно воспользоваться такими сложными технологиями, как DISCO компании Microsoft или регистрами служб - UDDI (Universal Description, Discovery and Integration), о котором и пойдет речь в этой статье.
UDDI
Стандарт UDDI описывает четыре элемента данных в рамках модели данных версии 1.0: businessEntity (моделирование бизнес-информации), businessService (описание службы высокого уровня), tModel (моделирование типа технологии или службы) и bindingTemplate (преобразование businessService между и элементами tModel). Я не собираюсь освещать сложную природу этих элементов, поэтому, если вам необходима базовая информация по этому вопросу, советую посетить сайт UDDI (см. Ресурсы).
Набор улов оператора, известный как бизнес UDDI-регистр или "покров" UDDI-оператора (UDDI operator cloud), подразумевает специфическую модель программирования, которая характеризуется обнаружением службы в период проектирования (design time).
Тем не менее, благодаря ценному предложению по своевременной интеграции (just-in-time integration) в рамках IBM Web Services Initiative организации могут динамически обнаруживать Web-службы и связываться с ними во время выполнения (run time). Для этого, характеристики API и другие нефункциональные требования определяются в период проектирования как бизнес-полисы (business policies). Эта гибкость имеет важные свойства для интеграции свободно связанных приложений в масштабах предприятия как в пределах одной, так и нескольких организаций.
В настоящее время возможности "покрова" UDDI в поддержании динамического стиля связывания Web-служб ограничены. Однако, UDDI API и стандарт модели данных все еще могут сыграть свою роль в сервис-ориентированной архитектуре. Понятие частного, или не являющегося оператором, UDDI-узла (private или non-operator UDDI node) имеет важное значение в появлении динамического стиля сервис-ориентированной архитектуры.
Шесть типов UDDI
В действительности UDDI состоит из двух частей: 1) "покрова" UDD-узлов оператора, репозитория глобальной сети (состоящего из "белых", "желтых" и "зеленых страниц") метаданных Web-служб; и 2) API и стандарта модели данных для репозитория метаданных Web-служб. Первый из них хранит данные, а второй обеспечивает средства доступа к ним.
Сейчас наиболее важной формой UDDI является "покров UDDI-оператора. Покров UDDI-оператора - это набор UDDI-узлов, координируемых соглашением оператора по обеспечению единообразного доступа к метаданным Web-служб из любого узла оператора. Если метаданные Web-служб введены в один узел оператора, их можно, с некоторой допустимой временной задержкой, извлечь из других узлов оператора. Узлы оператора совместно используют данные при помощи хорошо определенной схемы дублирования.
Структура стандарта UDDI допускает существование частных UDDI-узлов. Согласно спецификации UDDI v1.0, частный UDDI-узел может выполнять все UDDI API, но он не участвует в схеме дублирования, определяемой соглашением UDDI операторов.
Я выявил шесть разновидностей, или как я их назвал, шесть типов UDDI:
- Узел UDDI-оператора (UDDI Operator node).
- Е-рынок UDDI (e-marketplace UDDI).
- Портал UDDI (Portal UDDI).
- Партнерский каталог UDDI (Partner catalog UDDI) - также известный как Проверенные партнеры (Vetted partners) или rolodex-like UDDI.
- UDDI внутренней интеграции приложений предприятия (Internal Enterprise Application Integration UDDI).
- Испытательная модель UDDI (Test Bed UDDI).
Все перечисленные типы, кроме первого, считаются частными, или не являющимися оператором, узлами. По причине больших объемов данных, широты ассортимента продуктов, неоднородности самой отрасли и географического разнообразия, а также требования по соблюдению соглашения оператора, узлы оператора ограничены в возможности предоставления дополнительного или различного поведения.
Ниже кратко описаны все типы UDDI-узлов.
UDDI-оператор
Это как раз именно то, что обычно представляют, когда речь заходит о UDDI. Эти UDDI-узлы образуют средство покрова оператора, обратиться к которому можно с www.uddi.org (см. Ресурсы). Отличный пример этого типа - бизнес UDDI-регистр, который сейчас копируется между IBM, Microsoft и, в ближайшей перспективе, HP (см. Ресурсы). Ariba, в прошлом оператор, объявила, что она решила изменить специализацию и займется регистрацией Web-служб.
Е-рынок UDDI
Этот частный UDDI-узел содержится е-рынком: стандартной организацией или консорциумом организаций, которые входят в эту отрасль и являются конкурентами. В данном UDDI-узле, все Inquiry API (а именно, publish и find) размешаются любым членом этой ассоциации для доступа через Интернета.
Записи в этом типе UDDI относятся к отдельной отрасли или узкому диапазону связанных отраслей. Благодаря подобной практике членства записи могут быть предварительно отфильтрованы так, чтобы включать только легитимные компании для этой отрасли. Кроме того, эта процедура также позволяет ограничить тех, кто может вызвать операции поиска по UDDI-узлу. Например, ассоциация сталелитейных компаний могла бы содержать UDDI-узел и позволять своим членам регистрировать свои компании и Web-службы.
Е-рынок UDDI - мощная целевая среда обнаружения метаданных Web-служб для занятия бизнесом в рамках отдельного е-рынка или отрасли. На е-рынке UDDI было бы логично находить специализированные клиентские таксономии (иерархические структуры стандартного кодирования продуктов, специализации категорий NAICS [North American Industry Classification System, Система отраслевой классификации Северной Америки] и тому подобное), а также описания стандартного интерфейса Web-службы (tModels) для обычных бизнес-процессов данной отрасли. Например, изучив tModels, которые содержатся в е-рынке UDDI, поставщики могли определять какие типы размещений заказа на поставку обычно имеют место в сталелитейной промышленности. А как только в отраслях примут соглашение об описаниях стандартного интерфейса Web-служб, процесс развития и признания Web-служб испытает подъем.
Благодаря этой разновидности частных UDDI-узлов е-рынок может предложить дополнительные услуги: например, свойство службы, наблюдающей за временем ответа партнерских Web-служб, а также отраслевой самомониторинг лучших бизнес-методов членов в стиле Better Business Bureau.
Поиск в серьезных "машина-машина" (machine-to-machine, M2M) схемах B2B будет происходить в UDDI-узле е-рынка. Покупатель может запускать поиск по UDDI-узлу е-рынка во время подготовки издания запроса на использование ресурсов (request for quotes, RFQ) к различным поставщикам данной отрасли. Простой поиск по UDDI-узлу выявляет всех поставщиков, которые могут получить такой запрос посредством вызова Web-службы. Эти е-рынки будут стремиться перейти в область Web-служб, чтобы избежать вмешательства покрова UDDI-оператора.
Портал UDDI
Транзактная "всемирная паутина" отсылает к использованию Интернета для схемы M2M B2B. Точно также, как компания визуально присутствует в Интернете (http://www.acme.com), она будет представлена в транзактной "паутина" (http://www.acme.com/uddi). Я буду называть это представление в транзактной "паутина" порталом UDDI .
Обычно портал UDDI располагается в корпоративном брандмауэре в демилитаризованное зоне и является частным узлом, который содержит только метаданные, относящиеся к Web-службам компании. Так записи в http://www.acme.com/uddi показывают данные для Web-служб, которые acme.com желает предоставить внешним партнерам. Очевидно, что в интересах компании поддерживать доступ через Интернет к find API (API поиска), хотя publish API (API опубликования) будет, при этом, удален, допуская процедуру опубликования только внутри компании.
Когда acme.com пожелает разместить Web-службу, компания опубликует описание этой службы в своем портале UDDI. Тогда другие средства, которые будут рассмотрены дальше, будут автоматически вызваться, чтобы гарантировать, что метаданные новых Web-служб корректно отражаются в других UDDI-узлах, таких как покров оператора, различные е-рынки и каталоги ключевых партнеров.
Благодаря порталу UDDI компания получает полный контроль над тем, как используются метаданные, описывающие ее Web-службы. Например, компания может ограничить доступ к поиску. Она также может отслеживать число обращений к своим данным и управлять этим числом, а также получать информацию о заинтересованных сторонах.
По отношению к покрову UDDI-оператора URL для UDDI-узла транзактного Web-представления acme.com может использоваться как discoveryURL в записи businessEntity для acme.com.
Партнерский каталог UDDI
Этот частный UDDI-узел располагается за брандмауэром, и по нему выполняются поиск и связи. Он также содержит метаданные описания Web-службы, публикуемые надежными бизнес-партнерами (то есть теми организациями с которыми acme.com имеет формальные соглашения/связи). Поскольку publish и find API не доступны через Интернет, ко всем API могут обращаться только внутренние приложения.
Благодаря партнерскому каталогу организация может строить приложения, которые ориентированы на сервис, и использовать динамическое связывание с Web-службами через интерфейс Web-служб в период проектирования. API для Web-службы, в соответствии с реализацией описания интерфейса Web-служб (например, обычное использование WSDL с tModel), устанавливается во время проектирования. Но другие характеристики, такие как перенос (transport), стек безопасности (security stack) и некоторые другие, могут быть выполнены динамически в время выполнения. Приложения пишутся так, чтобы принимать любую Web-службу, которая соответствует поиску, выполненному по этому UDDI. Благодаря тому, что этот UDDI-узел содержит только одобренных бизнес-партнеров, при динамическом связывании не возникает опасности столкнуться с неизвестным поставщиком услуг.
Давайте рассмотрим следующий пример. Компании Buyer.com хочет с помощью технологии Web-служб приобрести е-бизнес вида M2M, чтобы снизить транзакционные расходы на решение задач логистики, например повторный заказ поставок, но ее руководство не желает ограничиваться только одним отдельным поставщиком. При этом, они согласны сотрудничать с acme.com. Специалисты IT-отдела компании Buyer.com могут изучить записи UDDI для acme.com (из покрова оператора, е-рынка или портала UDDI компании acme.com) и скопировать эти записи в свой собственный партнерский каталог UDDI Web-служб. Buyer.com может повторить эту процедуру для всех поставщиков, с которыми она намерена заниматься бизнесом. По мере того, как у компании будут формироваться новые деловые связи, а некоторые прежние распадаться, список поставщиков будет меняться, что потребует обновления UDDI-узла партнерского каталога этой компании.
Модули доступа (proxy) могут генерироваться из стандарта WSDL и приложений, написанных для выполнения поиска по UDDI-узлу партнерского каталога. Для того, чтобы отслеживать изменения, вносимые в список одобренных партнеров, не требуется переписывать эти приложения. Такое приложение использует записи UDDI для определения доступных Web-служб: выбирает, основываясь на данном бизнес-полисе, одну или несколько лучших для вызова Web-служб, а затем запускает эту Web-службу.
Для того, чтобы это динамическое связывание поддержки приложений было полным, UDDI-узел партнерского каталога может ограничивать функцию опубликования, допуская только записи, отвечающие определенному критерию (например, только элементы businessServices, связанные с tModel, основанным на WSDL, или только businessServices, которые поддерживают tModel заказа на поставку известного отраслевого стандарта). Благодаря этому администратор может обеспечить форму записей, которые располагаются в пределах UDDI-узла, и, следовательно, определить, какие приложения могут отвечать на операторы поиска.
UDDI-узел партнерского каталога также поддерживает дополнительные услуги: поиск businessServices, основанный на ключе tModel, или поиск businessServices, основанный на типе WSDL, независимо от того, поддерживает ли его бизнес. Эти дополнительные API обеспечивают сценарии, описанные выше.
UDDI внутренней интеграции приложений предприятия
Этот тип напоминает партнерский каталог за исключением того, что записи для Web-служб предоставляют другие отделы или группы в пределах организации. Основная отличительная особенность этого типа - потенциал для административного домена, который может диктовать стандарты (например, используемый элемент tModel, общее применение WSDL portTypes и так далее). Благодаря этому UDDI-узел может работать с различными ограничениями опубликования, а не с теми, которые предложены для партнерского каталога UDDI. Например, узел, чтобы принимать только записи, связанные с установленным набором tModel, мог бы ограничить опубликование новых tModel и, таким образом, ограничить опубликование businessServices и bindingTemplates.
Разумеется, этот тип полностью скрыт за брандмауэром компании. Операторы опубликования и поиска ограничивались бы приложениями в пределах организации.
Испытательная модель UDDI
Этот тип частного UDDI-узла тестирует приложения. Тестирование может применяться как к приложениям запросчика, так и поставщика Web-служб.
Если acme.com предоставляет доступ через Web-службы к своей системе размещения заказов на поставку, то эта компания использует этот тип UDDI-узла, чтобы гарантировать два момента: 1) что UDDI-записи ее Web-службы правильные, 2) что приложения могут использовать информацию Web-службы, чтобы сгенерировать модуль доступа из UDDI-записи для доступа к этой Web-службе.
Если acme.com создает приложения для использования Web-служб, компания проверяет возможность приложения соответствовать различным вариантам описания Web-службы с записями из испытательной модели UDDI. Понятно, что acme.com захочет выполнить испытание любой новой UDDI-записи, обнаруженной в покрове оператора, на е-рынке UDDI или в партнерском транзактном Web-представлении UDDI. Сначала должны быть скопированы записи. Затем проводится ряд тестов для подтверждения того, что приложение может использовать информацию, найденную в записи. И, наконец, только после тестирования, эта запись будет переведена в UDDI проверенных партнеров или в UDDI интеграции приложений предприятия.
Заключение
В данной статье рассказывается о роли, которую играет стандарт UDDI при обнаружении в рамках сервис-ориентированной архитепктуры. В ней также рассмотрены шесть типов UDDI, каждый из которых используется для поддержки различных применений этой архитектуры.
Ресурсы
- Сайт UDDI.
- Некоторые ресурсы UDDI.
- UDDI Browser.
- Реализация стандарта UDDI с открытым исходным кодом на JAVA.
- Проект UDDI4j.
- XML cover pages.
- UDDI-страницы корпорации Microsoft.
Автор: Стив Грэхем (Steve Graham)