Продолжается подписка на наши издания! Вы не забыли подписаться?

Java API for XML Registries

Автор: Александр Цимбал

Терминология
Репозитарий (Repository)
Реестр (Registry)
Registry provider
JAXR provider
Клиент JAXR
Профиль возможностей (Capability profile)
Принципы построения JAXR
Соединения и фабрики соединений
Интерфейс RegistryService и рабочие интерфейсы.
Возвращаемые значения
Объекты информационной модели JAXR
Запросы JAXR
Информационная модель JAXR
RegistryPackage
ExternalLink
Externalldentifier
Slot
Classification
ClassificationScheme
Concept
Association
AuditableEvent
User
Organization
PostalAddress и TelephoneNumber
Service
ServiceBinding
SpecificationLink
RegistryObject
InternationalString и LocalizedString
Основные Интерфейсы JAXR
Класс ConnectionFactory
Connection и FederatedConnection
RegistryService
LifeCycleManager
BusinessLifeCycleManager
QueryManager
DeclarativeQueryManager
Query
BusinessQueryManager
FindQualifiers
JAXRException и другие исключения
JAXRResponse
BulkResponse
Versionable
CapabilityProfile
Средства обеспечения безопасности
Отображение между JAXR и UDDI
Информационная модель UDDI
Методы UDDI Publisher API
Методы UDDI Inquiry API
Соответствия на уровне атрибутов
Пример соответствия информационных моделей JAXR и UDDI
Примеры JAXR-приложений
Выбор реестра для демонстрационных приложений
Размещение информации в реестре
Запрос к реестру
Заключение

Публикация информации о Web-сервисах с целью обеспечения доступа к ним для потенциальных клиентов является важнейшей частью технологии Web-сервисов. Вследствие этого консорциум JCP не мог не предпринять попытку создания универсального API, который должен обеспечить возможность создания переносимых Java-приложений с точки зрения опубликования соответствующей информации в реестрах и доступа к ней. Этим универсальным API и является JAXR (Java API for XML Registries).

К моменту начала разработки JAXR на практике широко использовались различные виды реестров информации о Web-сервисах. Наиболее популярными из них являлись (и являются) реестры ebXML (ebXML Registry) и UDDI. Спецификация JAXR создавалась не как «общее подмножество» возможностей различных технологий, а, скорее, как «сумма» таких возможностей.

Это означает, с одной стороны, что JAXR достаточно гибок для работы с различными реестрами. С другой стороны –не все возможности JAXR могут быть реализованы при работе с каждым конкретным видом реестра. В качестве основы при создании JAXR была принята технология ebXML Registry, как более гибкая и универсальная (по сравнению с UDDI). Спецификация JAXR содержит специальные разделы, подробно оговаривающие вопросы отображения элементов JAXR как на ebXML, так и на UDDI.

Терминология

Как всегда, начнем с рассмотрения основных терминов.

Репозитарий (Repository)

Под «репозитарием» применительно к JAXR понимается долговременное хранилище (база данных), в котором хранятся конкретные описания – DTD, XML-схемы, WSDL-документы, другие виды информации. Каждый из таких фрагментов информации называется «элементом репозитария» (repository item).

Реестр (Registry)

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

JAXR не определяет никаких формальных правил для доступа непосредственно к репозитарию. Наоборот, с точки зрения JAXR клиенты не должны иметь доступ к репозитарию вообще – вместо этого они должны обращаться за помощью только и исключительно к реестру. Следовательно, JAXR API не описывает типы элементов репозитария – вместо этого в нем описываются так называемые «объекты реестра» (Registry Objects), которые нужны для управления соответствующими элементами репозитария.

Registry provider

Итак, имеется два программных слоя, которые совместно используются Java-программистом для написания универсальных программ, имеющих доступ к информации о Web-сервисах. Оба этих слоя не разрабатываются прикладным программистом, а используются им в «готовом виде». Тот слой, который обеспечивает реализацию реестра, должен быть создан «провайдером реестра» (Registry Provider).

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

JAXR provider

При использовании JAXR прикладной программист не обращается непосредственно к API, предоставляемому провайдером реестра. Вместо этого он использует JAXR API, и обеспечивает реализацию этого API «провайдер JAXR». API от провайдера JAXR, взаимодействуя (прозрачным для прикладного программиста образом) с API от провайдера реестра, решает очень многие серьезные и сложные вопросы. В частности, это воспросы обеспечения безопасности при работе с реестром.

Клиент JAXR

Поскольку, как мы видим, работа осуществляется в классическом стиле «клиент-сервер» с использованием чего-то похожего на драйверную архитектуру, то приложения, создаваемыми прикладными программистами с использованием JAXR, всегда являются клиентскими приложениями. Часть клиентских приложений заносит информацию в реестр, часть – извлекает ее из реестра.

Клиентские приложения JAXR могут быть реализованы самыми различными способами – они могут быть независимыми Java-приложениями, приложениями в формате J2EE и т.д. Клиентские приложения используют JAXR API для доступа к серверной части, реализованной провайдером JAXR.

Профиль возможностей (Capability profile)

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

Чтобы как-то управлять уровнем переносимости клиентских приложений, спецификация JAXR вводит понятие «профиля возможностей». В настоящий момент определены два уровня – уровень (level) 0 и уровень 1.

Тот или иной уровень сопоставляется непосредственно с каждым методом (не классом или интерфейсом!) JAXR API. Программист может получить информацию об уровне, который поддерживает тот или иной провайдер JAXR, с помощью специального интерфейса – CapabilityProfile.

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

Что касается поддержки UDDI и ebXML, то спецификация требует следующее: JAXR-провайдеры для поддержки UDDI должны соответствовать уровню 0, для поддержки ebXML – уровню 1.

..............

Заключение

Использование JAXR существенно упрощает такую важнейшую часть работы разработчика Web-сервисов, как помещение информации в XML-реестр и извлечение ее из него. Хотя обычно такого рода действия выполняются не программно, а с помощью готовых графических средств, рассчитанных на конечного пользователя, задача программного взаимодействия с реестрами возникает достаточно часто, в том числе тогда, когда вы хотите создать собственное средство для работы с реестрами, «оптимизированное» для нужд конкретного проекта или конкретной организации. В связи с широким использованием различных технологий поддержки XML-реестров наличие универсального программного API, не зависящего (или очень слабо зависящего) от конкретной реализации, часто позволяет решать важные проблемы.

"С полным содержанием данной статьи можно ознакомиться в печатной версии журнала"

Copyright © 1994-2016 ООО "К-Пресс"