Spec-Zone .ru
спецификации, руководства, описания, API
|
СОДЕРЖАНИЕ | ПРЕДЫДУЩИЙ | NEXT |
Мы следовали за несколькими принципами и принципами в разработке API.
Везде, где возможный, мы использовали существующие компоненты от остальной части среды разработки Java. Соблюдение этого принципа не только делает JNDI непротиворечивый с существующими базовыми классами в платформе Java, но также и уменьшает бесполезное быстрое увеличение классов.
Объектно-ориентированная природа языка программирования Java учитывает интуитивный и простой проект API, в котором функциональность службы каталогов выражается как естественное расширение более фундаментальной функциональности службы именования.
API структурируется разделенным на уровни способом так, чтобы прикладной программист, заинтересованный определенной возможностью службы каталогов, обязательно не знал о более усовершенствованной возможности. Мы стремились сохранить нижние ярусы простыми и также заставить их представить возможность общего падежа, понижая более сложные к верхним уровням.
Эта цель важна по двум причинам. Во-первых, это позволяет приложениям Java использовать в своих интересах информацию во множестве существующего именования и служб каталогов, таких как DNS, NDS, NIS (YP), X.500, и LDAP. Во-вторых, это помогает ограничить появление любой реализации определенные артефакты в API.
Обеспечение объединенного интерфейса к многократному именованию и службам каталогов не подразумевает, что доступ уникальных функций определенной службы устраняется. Объединенный API, который разрабатывается, чтобы покрыть общий падеж, все еще выгоден для приложений, у которых есть явно заданные знания базового именования или службы каталогов. Такие приложения все еще извлекают выгоду из совместного использования общих частей, которые используют API. Это походит на приложения, совместно использующие обычно используемые классы и все же добавляющие необходимую специфику через разделение на подклассы.
Это важно не только из-за разнообразия службы каталогов и служб именования в установленной основе, которая должна поддерживаться, но также и потому что новое приложение Java и программисты службы могут экспортировать их собственные пространства имен и объекты каталога универсальным способом.
Мы также хотели сделать множество вариантов реализации возможным, не имея плату приложения за эту свободу. Например, "тонкий клиент" мог бы быть лучше подан протоколом стиля прокси, в котором доступ к определенному именованию и службам каталогов понижается к серверу. Принимая во внимание, что, чувствительная производительность, толстый клиент ресурса, могла бы хотеть использовать реализацию, которая непосредственно позволяет этому получать доступ к различным серверам. Однако, приложение должно быть изолировано от этих вариантов реализации. Должно быть возможно задержать такие варианты даже до времени выполнения.
Легкий Протокол Доступа Каталога (Интернет RFC 2251) появился в качестве стандарта для доступа каталога на уровне протокола. У всех главных поставщиков каталога есть продукты, которые поддерживают этот протокол. Приложение, которое использует JNDI, должно быть в состоянии получить доступ ко всем функциям, предлагаемым этим стандартом. Где только возможно JNDI должен поддерживать соглашения (такие как те для того, чтобы определить поисковые запросы/фильтры) уже определенный стандартом.
СОДЕРЖАНИЕ | ПРЕДЫДУЩИЙ | NEXT