2.1 Сохраните это непротиворечивым и интуитивным

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

Объектно-ориентированная природа языка программирования Java учитывает интуитивный и простой проект API, в котором функциональность службы каталогов выражается как естественное расширение более фундаментальной функциональности службы именования.

2.2 Плата за то, что Вы используете

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

2.3 Implementable по общему каталогу и службам именования и протоколам

Эта цель важна по двум причинам. Во-первых, это позволяет приложениям Java использовать в своих интересах информацию во множестве существующего именования и служб каталогов, таких как DNS, NDS, NIS (YP), X.500, и LDAP. Во-вторых, это помогает ограничить появление любой реализации определенные артефакты в API.

Обеспечение объединенного интерфейса к многократному именованию и службам каталогов не подразумевает, что доступ уникальных функций определенной службы устраняется. Объединенный API, который разрабатывается, чтобы покрыть общий падеж, все еще выгоден для приложений, у которых есть явно заданные знания базового именования или службы каталогов. Такие приложения все еще извлекают выгоду из совместного использования общих частей, которые используют API. Это походит на приложения, совместно использующие обычно используемые классы и все же добавляющие необходимую специфику через разделение на подклассы.

2.4 Интеграция без шва

Это важно не только из-за разнообразия службы каталогов и служб именования в установленной основе, которая должна поддерживаться, но также и потому что новое приложение Java и программисты службы могут экспортировать их собственные пространства имен и объекты каталога универсальным способом.

Мы также хотели сделать множество вариантов реализации возможным, не имея плату приложения за эту свободу. Например, "тонкий клиент" мог бы быть лучше подан протоколом стиля прокси, в котором доступ к определенному именованию и службам каталогов понижается к серверу. Принимая во внимание, что, чувствительная производительность, толстый клиент ресурса, могла бы хотеть использовать реализацию, которая непосредственно позволяет этому получать доступ к различным серверам. Однако, приложение должно быть изолировано от этих вариантов реализации. Должно быть возможно задержать такие варианты даже до времени выполнения.

2.5 Поддержка продвижения промышленных стандартов

Легкий Протокол Доступа Каталога (Интернет RFC 2251) появился в качестве стандарта для доступа каталога на уровне протокола. У всех главных поставщиков каталога есть продукты, которые поддерживают этот протокол. Приложение, которое использует JNDI, должно быть в состоянии получить доступ ко всем функциям, предлагаемым этим стандартом. Где только возможно JNDI должен поддерживать соглашения (такие как те для того, чтобы определить запросы/фильтры поиска) уже определенный стандартом.

СОДЕРЖАНИЕ | ПРЕДЫДУЩИЙ | NEXT