Технология Клиент-Сервер 2004'2 |
|||||||
|
Публикация информации о 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.
Как всегда, начнем с рассмотрения основных терминов.
Под «репозитарием» применительно к JAXR понимается долговременное хранилище (база данных), в котором хранятся конкретные описания – DTD, XML-схемы, WSDL-документы, другие виды информации. Каждый из таких фрагментов информации называется «элементом репозитария» (repository item).
Чтобы клиенты могли помещать информацию в репозитарий или извлекать ее из него, необходима «система управления репозитарием». Важнейшей задачей такой системы является создание и поддержка информации о видах, типах, структуре и связях элементов репозитария, т.е. метаданных о хранимой информации. Решение этой задачи и должен обеспечивать Реестр.
JAXR не определяет никаких формальных правил для доступа непосредственно к репозитарию. Наоборот, с точки зрения JAXR клиенты не должны иметь доступ к репозитарию вообще – вместо этого они должны обращаться за помощью только и исключительно к реестру. Следовательно, JAXR API не описывает типы элементов репозитария – вместо этого в нем описываются так называемые «объекты реестра» (Registry Objects), которые нужны для управления соответствующими элементами репозитария.
Итак, имеется два программных слоя, которые совместно используются Java-программистом для написания универсальных программ, имеющих доступ к информации о Web-сервисах. Оба этих слоя не разрабатываются прикладным программистом, а используются им в «готовом виде». Тот слой, который обеспечивает реализацию реестра, должен быть создан «провайдером реестра» (Registry Provider).
Этот программный слой не является универсальным в том смысле, что рассчитан только и исключительно на работу с конкретным видом и конкретной реализацией XML-реестра.
При использовании JAXR прикладной программист не обращается непосредственно к API, предоставляемому провайдером реестра. Вместо этого он использует JAXR API, и обеспечивает реализацию этого API «провайдер JAXR». API от провайдера JAXR, взаимодействуя (прозрачным для прикладного программиста образом) с API от провайдера реестра, решает очень многие серьезные и сложные вопросы. В частности, это воспросы обеспечения безопасности при работе с реестром.
Поскольку, как мы видим, работа осуществляется в классическом стиле «клиент-сервер» с использованием чего-то похожего на драйверную архитектуру, то приложения, создаваемыми прикладными программистами с использованием JAXR, всегда являются клиентскими приложениями. Часть клиентских приложений заносит информацию в реестр, часть – извлекает ее из реестра.
Клиентские приложения JAXR могут быть реализованы самыми различными способами – они могут быть независимыми Java-приложениями, приложениями в формате J2EE и т.д. Клиентские приложения используют JAXR API для доступа к серверной части, реализованной провайдером JAXR.
Поскольку 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 ООО "К-Пресс"