[an error occurred while processing this directive] IT • archiv :: Print

IT • archiv


[an error occurred while processing this directive]

[an error occurred while processing this directive]

Обзор JNDI, Часть 2: Введение в сервисы каталогов

[an error occurred while processing this directive](none) [an error occurred while processing this directive](none)[an error occurred while processing this directive] ::
[an error occurred while processing this directive](none)
[an error occurred while processing this directive]([an error occurred while processing this directive] Тод Сандстед [an error occurred while processing this directive])

[an error occurred while processing this directive](none)

Используйте сервисы каталогов для лучшего контроля над распределенными приложениями.

How-To Java
PDF versionPDF версия
Обзор
Когда приложения становятся более распределенными, эффективное управление и распределение информации, от которой они зависят, становится все большей проблемой. Сервисы каталогов, такие как LDAP (the Lightweight Directory Access Protocol — Легковесный Протокол Доступа к Каталогам) помогают в решении этой проблемы. Для приложений Java, the Java Naming and Directory Interface (JNDI) обеспечивает исходный интерфейс для LDAP и других сервисов каталогов. В этом месяце Тод Сандстед познакомит вас с сервисами каталогов JNDI. (1300 слов)

Давайте с вами на минуту вернемся к исходной точке. Я познакомил вас с такой старой организацией, как библиотека. Я сделал это для того, чтобы показать аналогию между физическим инструментом, таким как библиотечный каталог и програмным инструментом- сервисом имен. Ключевым для этой аналогии было простое намерение найти что-либо по имени в централизованном хранилище, чтобы быстро определить его местонахождение. В библиотеке, картотека содержит пути к книгам на стелажах; в распределенных системах сервис имен переводит имена объектов в их местонахождения в сети. Оба эти инструмента черезвычайно полезны в своих областях.

Как оказывается, с небольшими усилиями я могу провести эту аналогию дальше. Видите-ли, карточка в картотеке содержит больше информации, чем простое место книги; она также содержит имя автора, дату издания, количество страниц и множество других полезных данных. Я могу узнать довольно много о книге даже не держа ее в руках.

В области програмного обеспечения, инструменты, которые обеспечивают такого рода информацию известны как каталоги (directories). Оказывается, технология разработанная давным-давно библиотекарями может оказатся полезной для программистов (интересно, какие еще маленькие сокровища могут скрываться в организации ближайшей библиотеки).

Введение в сервисы каталогов.

Сервис каталогов обеспечивает возможность для управления хранением и распространением общей информации. Такой информацией могут быть адреса email и телефоны сотрудников компании, IP адреса и ресурсы печати в принтерах отдела, и даже настроечная информация серии серверов приложений.

Схема внизу отображает простой сервис каталогов.

Простой сервис каталогов.
Рисунок 1. Простой сервис каталогов.

Сервис каталогов управляет каталогом с набором вхождений (entries). Вхождение каталога может указывать на человека, место, сервис или практически любой другой конкретный объект или абстрактное понятие. Вхождение также содержит атрибуты (attributes), связанные с ним; атрибуты состоят из имени или идентификатора и одного или более значений. Атрибуты описывают вхождение и конкретный набор атрибутов зависит от типа вхождения. Например, вхождение для человека может содержать следующие атрибуты (заметьте 2 адреса email):

Name: John Doe
Address: 123 Somewhere Street
Email: john@xyz.com
Email: jdoe@abcd.com

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

Сервисы имен и сервисы каталогов логические партнеры. На самом деле, большинство существующих продуктов обеспечивают оба набора функциональности. Сервисы имен обеспечивают поиск объекта по имени, а сервисы каталогов предоставляют информацию об объектах и инструменты для их поиска.

Существует ряд продуктов с сервисами каталогов; LDAP (the Lightweight Directory Access Protocol) наиболее распространенный. LDAP обеспечивает сервисы как имен, так и каталогов. Существует масса коммерческих реализаций, также, как и доступные бесплатно (OpenLDAP один из популярных — см. раздел Ресурсы).

Существуют описания различных сервисов каталогов в январской колонке How-To Java .

Взгляд на сервисы каталогов JNDI

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

Держа это в уме, давайте изучим класс DirContext — сердце сервисов каталогов JNDI.

Работа с атрибутами

Класс DirContext является подклассом класса Context, описанного в прошлом месяце. Он обеспечивает всю стандартную фунциональность сервисов имен, и также может работать с атрибутами и искать вхождения в каталоги.

Давайте посмотрим на методы в DirContext, которые расширяют методы класса Context.

Метод bind()

void
bind(
 String stringName,
 Object object,
 Attributes attributes
)

Метод bind() привязывает имя к объекту и сохраняет набор атрибутов с этим вхождением. Такая операция вцелом пытается сохранить существующие атрибуты в тех случаях, когда это имеет смысл. В частности, если attributes равны null и object является порождением класса DirContext, результирующая связка будет содержать атрибуты, котрые изначально были привязаны к object.

Метод rebind()

void
rebind(
 String stringName,
 Object object,
 Attributes attributes
)

Метод rebind() привязывает имя к объекту и сохраняет набор атрибутов с этим вхождением. Предыдущая связка замещается новой. Так же, как и в случае с bind(), эта операция вцелом пытается сохранить существующие атрибуты в тех случаях, когда это имеет смысл.

Метод createSubcontext()

DirContext
createSubcontext(
 String stringName,
 Attributes attributes
)

Метод createSubcontext() создает новый подконтекст (subcontext), привязывает к нему имя и сохраняет набор атрибутов с этим вхождением. Если attributes равны null, этот метод работает совершенно так же, как одноименный метод и класса Context.

Теперь давайте рассмотрим методы DirContext, которые не расширяют методы класса Context и дают возможность работать с атрибутами.

Методы getAttributes()

Этот класс содержит две разновидности таких методов:

Attributes
getAttributes(
 String stringName
)

И:

Attributes
getAttributes(
 String stringName,
 String [] rgstringAttributeNames
)

Методы getAttributes возвращают атрибуты, связанные с определенным вхождением. Класс Attributes представляет коллекцию атрибутов; он содержит порождения класса Attribute, который, в свою очередь, представляет одиночный атрибут. Первая разновидность этого метода возвращает все атрибуты, и вторая- атрибуты, представленные во вспомогательном массиве имен атрибутов.

Методы modifyAttributes

modifyAttributes также бывает двух типов:

void
modifyAttributes(
 String stringName,
 int nOperation,
 Attributes attributes
)

И:

void
modifyAttributes(
 String stringName,
 ModificationItem [] rgmodificationitem
)

Метод modifyA ttributes изменяет атрибуты, связанные с определенным вхождением. Разрешены операции ADD_ATTRIBUTE, REPLACE_ATTRIBUTE, и REMOVE_ATTRIBUTE. Первая разновидность этого метода изменяет несколько атрибутов одинаковым образом, тогда как вторая выполняет последовательность изменений для одного или нескольких атрибутов.

Для класса Context каждый из этих методов также имеет вариант, который берет объект Name, а не String.

Поиск

Для того чтобы можно было использовать функциональность сервисов каталогов, необходимо иметь возможность проводить поиск в содержимом сервисов каталогов. Класс DirContext обеспечивает две основные модели для проведения поиска.

Поиск по имени атрибута

Существует два пути для проведения поиска следуя этой модели:

NamingEnumeration
search(
 String stringName,
 Attributes attributesToMatch
)

И:

NamingEnumeration
search(
 String stringName,
 Attributes attributesToMatch,
 String [] rgstringAttributesToReturn
)

Для первой модели, поиск происходит внутри одиночного контекста для вхождений, котрые содержат определенный набор атрибутов. Для вхождений, соответствующих критериям поиска, запрос возвращает либо весь набор атрибутов (если поиск реализован с помощью первого блока кода, приведенного выше), или избранную часть набора (в случае второго блока).

Теперь давайте посмотрим на вторую модель.

Поиск с использованием фильтра RFC 2254

Снова, есть два пути для реализации этой модели:

NamingEnumeration
search(
 Name stringName,
 String stringRFC2254Filter,
 SearchControls searchcontrols
)

И:

NamingEnumeration
search(
 Name             stringName,
 String           stringRFC2254Filter,
 Object []        stringRFC2254FilterArgs,
 SearchControls   searchcontrols
)

Для второй модели поиск выполняется в пределах набора вхождений, соответствующего фильтру поиска. RFC 2254 (который описывает строковое представление для фильтров поиска LDAP — см. Ресурсы) определяет формат фильтра.

Порождение класса SearchControls управляет ключевыми моментами поиска:

SearchControls(
 int              nSearchScope,
 long             nEntryLimit,
 int              nTimeLimit,
 String []        rgstringAttributesToReturn,
 boolean          boolReturnObject,
 boolean          boolDereferenceLinks
)

Конструктор выше перечисляет все особенности поиска, которыми управляет порождение класса SearchControls. Существуют также соответствующие методы доступа (get и set методы). Я перечислю все эти особенности и их краткие описания:

  • nSearchScope: Устанавливает диапазон поиска либо для объекта (OBJECT_SCOPE), объекта и уровня непосредственно ниже него (ONELEVEL_SCOPE), или объекта и всей ветви (SUBTREE_SCOPE).
  • nEntryLimit: Устанавливает максимальное количество возвращаемых вхождений.
  • nTimeLimit: Устанавливает максимальное время в миллисекундах для проведения поиска.
  • rgstringAttributesToReturn: Определяет, какой атрибут должен быть возвращен вместе со вхождениями- результатами поиска.
  • boolReturnObject: Определяет, должны ли быть возвращены объекты, связанные со вхождениями- результатами поиска.
  • boolDereferenceLinks: Определяет, должны ли быть разорваны ссылки или перенаправлены на новые вхождения- результаты поиска. Ссылка (link) указывает на другой каталог и может распространятся на несколько сервисов имен. Не все реализации JNDI, однако, поддерживают ссылки.

Опять-таки, каждый вышеприведенный метод также содержит варианты которые используют объект Name, а не String.

Заключение

Если вы дочитали до этого места, вы должны получить четкое представление как о сервисах имен и каталогов, так и общее понимание JNDI. В следующем месяце мы пополним коллекцию полезных инструментов JNDI. Так как JNDI требует существования низкоуровневого провайдера услуг для своей работы, мы также рассмотрим построение и установку некоторых бесплатно-доступных реализаций LDAP.

Об авторе

Тод Сандстед писал программы с тех времен, когда компьютеры стали доступны как удобные настольные модели. Несмотря на то, что изначально его интересовало построение распределенных систем на C++, Тод перешел на Java, когда стало очевидно, что это лучший инструмент для подобных задач. Помимо написания статей, он работает как архитектор Java architect в ComFrame Software.

Ресурсы

Reprinted with permission from the February 2000 edition of JavaWorld magazine. Copyright © ITworld.com, Inc., an IDG Communications company.
View the original article at: http://www.javaworld.com/javaworld/ jw-02-2000/jw-02-howto.html

[an error occurred while processing this directive]
[an error occurred while processing this directive] Перевод на русский © Сергей Миссан, 2000
< Вернуться на caйт :: Copyright © 1999 — 2010, IT • archiv.