Spec-Zone .ru
спецификации, руководства, описания, API
|
|
Spec-Zone .ru
спецификации, руководства, описания, API
|
| СОДЕРЖАНИЕ | ПРЕДЫДУЩИЙ | NEXT |
В JNDI есть два базовых интерфейса: Context , и DirContext , с DirContext расширение основных операций именования в Context с операциями службы каталогов. Они были разделены на отдельные интерфейсы и для модульного принципа и также в соответствии с "платой за то, что Вы используете" цель JNDI.
Именование является основным компонентом, найденным во многих вычислительных сервисах, таких как файловые системы, электронные таблицы, календарные службы, и службы каталогов. При наличии основы Context интерфейс для операций именования, мы включаем его использованию всеми этими другими службами, не только для служб каталогов.
DirContext расширяется Context обеспечить основные операции службы каталогов, которые включают манипулирование атрибутами, связанными с именованными объектами, основанными на атрибуте поисками, и связанными со схемой операциями тех атрибутов и названных объектов.
JNDI разделяется на четыре клиентских пакета ( javax.naming , javax.naming.directory , javax.naming.event , javax.naming.ldap ) и пакет поставщика услуг ( javax.naming.spi ). Идея состоит в том, что каждый пакет содержит интерфейсы и классы, требуемые для определенной категории приложений, снова в соответствии с "платой за то, что Вы используете" цель. Например, приложение, которое только хочет выполнить поиски имени только, должно использовать javax.naming пакет. Приложение, которое хочет исследовать/изменить атрибуты, связанные с объектом, использует javax.naming и javax.naming.directory пакеты. Приложение, которое должно использовать LDAP-специфичные средства управления или расширенные операции, использует javax.naming.ldap пакет. Есть постепенная прогрессия того, с какими классами и соединяет интерфейсом, каждая категория писателя приложения должна изучить и использовать.
JNDI разделяет интерфейсы и классы, которые клиентское приложение должно использовать от тех, которые имеют только интерес для поставщиков услуг в различные пакеты. Например, клиент использовал бы интерфейсы и классы от javax.naming , в то время как поставщик услуг, который является присоединением служба именования, использовал бы обоих javax.naming и javax.naming.spi . Формирование рисунка пакета минимизирует беспорядок для разработчика приложений и ясно дает понять, какие пакеты он должен исследовать при записи его программы.
Есть два общих типа приложений, которые перечисляют контексты: приложения стиля браузера, и приложения, которые должны выполнить операции на объектах в контексте в массе. Приложения стиля браузера обычно хотят вывести на экран имена содержания контекста. В дополнение к именам много браузеров часто запрашивают информацию типа объектов, связанных с именами, так, чтобы она могла вывести на экран соответствующие графические представления объектов. Браузер является обычно интерактивным. Как только пользователь использовал браузер, чтобы вывести на экран содержание контекста, он тогда выбрал бы один или несколько из выведенных на экран записей и запросил бы больше информации о ней.
Некоторые приложения должны выполнить операции на объектах в пределах контекста в массе. Например, резервная программа могла бы хотеть выполнить "файл stats" операции на всех объектах в каталоге файла. Программа администрирования принтера могла бы хотеть перезапустить все принтеры в здании. Чтобы выполнить такие операции, эти программы должны получить все объекты, связанные в контексте.
С этими двумя общими стилями использования в памяти, Context у интерфейса есть два типа методов списка: list() и listBindings() . list() возвращает список name/class-name пар в то время как listBindings() возвращает список name/class-name/object кортежей. list() разрабатывается для приложений стиля браузера, которые хотят главным образом только имена и типы объектов, связанных в контексте. listBindings() для приложений, которые хотят потенциально получить все объекты в контексте, так же как их имена и типы. listBindings() возвращает перечисление Binding . Оба listBindings() работа непосредственно и вызов методов в Binding class (например. getObject() ) мог быть реализован лениво или нетерпеливо. Используя listBindings() просто указывает на потенциал, что вызывающая сторона могла бы хотеть все или многие из объектов в контексте так, чтобы реализации, которые в состоянии, могли оптимизировать для этого. Используя list() указывает, что вызывающая сторона вряд ли будет хотеть все, если таковые вообще имеются, объекты в контексте, таким образом, реализации смогут оптимизировать для этого если возможный.
Альтернатива должна иметь единственную работу списка и иметь ленивое или нетерпеливое поведение как часть реализации Binding . Преимущество этого состоит в том, что есть единственная работа списка, чтобы учиться. Недостаток - то, что у вызывающей стороны нет никакого способа указать, какую информацию он хочет назад от списка, и впоследствии, реализации не могут оптимизировать для возможного поведения программы.
Федерация является первым-class понятием в JNDI. В клиентских интерфейсах это поддерживается при помощи Name интерфейс для того, чтобы определить имена, которые могут охватить одно или более пространств имен. Вызывающая сторона методов в клиентском интерфейсе не должна знать ничто больше относительно федерации. Разрешение имен через многократные системы обрабатывается SPI и не включает вмешательства со стороны вызывающей стороны.
Хотя федерация является первым-class понятием, которое не означает, что все вызывающие стороны и поставщики услуг должны использовать ее. Если приложение или служба не хотят обманывать федерацию, нет никакого требования этого Name всегда охватывайте многократные пространства имен. Name может только назвать объекты в пределах единого пространства имен, и SPI может обработать разрешение имени в пределах единого пространства имен также (как выродившийся случай многократной поддержки пространства имен).
Вместо наличия DirContext расшириться Context , альтернатива не должна была бы расшириться Context во всех кроме вызвать отдельный интерфейс DirObject это инкапсулирует все связанные с каталогом методы. В этом случае объект может реализовать обоих Context и DirObject если это поддерживает и именование и операции каталога; другой объект мог бы реализовать только DirObject .
Проблема с устранением DirContext это DirContext содержит некоторые гибридные операции, которые включают и именование и каталоги ( bind() , createSubcontext() методы, которые принимают атрибуты как параметры). Сохранить эти операции и иметь DirObject одновременно произвел бы потребность в третьем интерфейсе (возможно, вызванный DirContext ) содержать только эти гибриды.
Кроме того, наличие DirContext вместо DirObject несколько более удобно в этом, можно выполнить некоторые операции за один шаг вместо два. Например DirContext.getAttributes() мог использоваться, чтобы связать атрибуты с именованным объектом, тогда как с DirObject , Вы должны были бы сначала решить к объекту ( Context.lookup() ) и затем используйте DirObject.getAttributes() получить атрибуты от этого.
DirContext интерфейс содержит поддержку схем. Например, от a DirContext объект можно получить его объект схемы, который указывает на пространство для каталога где схема для этой детали DirContext экземпляр определяется. От a DirContext объект, можно также получить его схему определение class (то есть информация о том, какой объект это представляет в каталоге). Есть дальнейшая поддержка схем в Attribute class, который содержит методы для того, чтобы получить информацию о синтаксисе атрибута (то есть что является типом значения атрибута) и определение атрибута (например, это многозначный, синтаксис, ограничения на его синтаксис). Нет никакого требования, что любая эта информация о схеме быть динамически доступным (то есть указывает, чтобы жить пространства для каталога). Поддержка такой информации о схеме могла быть сгенерирована статически поставщиком услуг. Например, определенная служба каталогов могла бы только поддерживать строковые значения атрибута, таким образом, она может соединить синтаксис проводами атрибутов, что она возвращается. Другой каталог мог бы поддерживать только статические схемы (где информация в схеме не является поддающейся изменению). Еще один каталог мог бы поддерживать полностью динамические схемы. Интерфейсы и классы в DirContext достаточно гибки, что эти разные уровни поддержки схем могут быть размещены.
Для каждого метода в Context и DirContext интерфейсы, который принимает a Name параметр, есть соответствующая перегруженная форма, которая принимает a String параметр за определение имени.
Побуждение для того, чтобы иметь String На основе методы - то, что есть много приложений, которые просто принимают имя строки от конечного пользователя и выполняют методы контекста на объекте, названном тем именем строки. Для тех приложений полезно иметь методы контекста, принимают строку для имени непосредственно, вместо того, чтобы требовать, чтобы приложения сначала создали a Name объект используя имя строки.
Побуждение для того, чтобы иметь Name На основе методы - то, что есть также много приложений, которые управляют именами и не хотят волноваться о синтаксических деталях строковых форм имен, сочиняя и изменяя имена. Эти приложения соглашение с проанализированной формой имен и следовательно предпочли бы иметь дело с Name объекты, а не названия строк. Для этих приложений мы обеспечиваем Name На основе методы в интерфейсах контекста. Не обеспечение этих методов, вероятно, вызвало бы быстрое увеличение Name - как интерфейсы/классы, чтобы поддерживать манипулирование именами в их структурной форме в приложениях, разработанных сверху JNDI.
Есть различные пути, которыми приложения и службы могут использовать каталог, чтобы определить местоположение объектов. JNDI является достаточно общим, что он размещает несколько различных моделей. Для некоторых приложений объект, связанный в каталоге, является объектом непосредственно. Приложение может создать динамический каталог, в то время как приложение является активным, и удалите каталог, когда приложение выходит. Другое приложение могло бы сохранить URL как атрибуты для того, чтобы определить местоположение объектов в его пространстве имен. Другие системы могли бы связать некоторую информацию о ссылке в каталоге, который может впоследствии использоваться, чтобы определить местоположение или получить доступ к фактическому объекту. Этот последний случай довольно распространен, специально для подавания заявок Java используют в своих интересах службы в установленной основе. Ссылка в каталоге действует как "указатель" на реальный объект.
JNDI определяет a Reference class, чтобы обеспечить универсальный способ представить информацию о ссылке. A Reference содержит информацию о том, как получить доступ к объекту. Это состоит из списка адресов и информации о class об объекте, к которому обращается эта ссылка. Связывая имя к объекту, который должен быть представлен в каталоге как ссылка, требуемый эффект состоит в том, что ссылка объекта извлекается и связанной. Чтобы учесть это поведение, class объекта должен реализовать Referenceable интерфейс, который содержит метод getReference() .
Между интерфейсами есть некоторое подобие Serializable и Referenceable и естественный вопрос, "почему не только используют Serializable вместо этого?" Ответ - то, что сериализированный объект является действительно замороженной версией объекта, тогда как ссылка содержит только информацию, должен был создать это. У сериализированной версии может быть намного больше состояния, которое, возможно, не является подходящим для хранения в каталоге.
Для объекта, который связывается как a Reference в каталоге платформа SPI JNDI автоматически создает и инстанцирует объекта, идентифицированного ссылкой. Таким образом программа может просто сузить результат lookup() к ожидаемому class, вместо того, чтобы вызвать отдельную работу, чтобы преобразовать результат lookup() в объект ожидаемого class.
Например, если бы Вы ищете объект принтера, успешный поиск возвратился бы к Вам, принтер возражает, что можно непосредственно использовать.
Printer prt = (Printer) ctx.lookup(somePrinterName); prt.print(someFileName);
JNDI делает это автоматически, вместо того, чтобы требовать явного шага преобразования, потому что это, как ожидают, будет образцом общего пользования. При наличии Reference class, и общий механизм для того, чтобы преобразовать a Reference в объект, идентифицированный Reference , JNDI поощряет различные приложения и поставщиков системы использовать этот механизм, вместо того, чтобы изобретать отдельные механизмы самостоятельно.
СОДЕРЖАНИЕ | ПРЕДЫДУЩИЙ | NEXT
