Доступ к корпоративным ресурсам через клиент JNDI - PullRequest
Новая
       1

Доступ к корпоративным ресурсам через клиент JNDI

1 голос
/ 23 февраля 2012

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

Этот шаблон состоит изклиент явно указывает JNDI серверу, который он ожидает разрешить данный ресурс, с помощью свойства url провайдера jndi.

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

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

    env.put (Context.PROVIDER_URL, "serverA:1100,serverB:1100,serverC:1100")

Сама реализация JNDI должна выяснить, какая служба разрешает данный ресурс на основе согласованной схемы именования.

Это жизнеспособный и вероятный подход?

1 Ответ

0 голосов
/ 01 марта 2012

Шаблон URL, который вы описали («serverA: 1100, serverB: 1100, serverC: 1100»), уже принят некоторыми реализациями InitialContext серверов приложений, но используется для определения LOAD BALANCE для достижения начальных контекстов в кластере!

Например, если вы используете этот URL-адрес в Weblogic Server, он будет использовать алгоритм циклического перебора для получения доступного начального контекста с серверов в списке.Он не будет использовать логику, описанную вами во время поиска, но только для подключения к начальному контексту.

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

Шаблон локатора службы также можно использовать для выполнения этой логики на уровне приложений.

В спецификации не определены правила для provider_url.просто говорит, что использование этого свойства определяется исходной реализацией контекста.Так что это правдоподобно, но не будет интуитивно понятным, если оно уже используется для определения балансировки нагрузки.Другая проблема заключается в том, что спецификация Java EE не гарантирует ничего о именах привязки JNDI для компонентов EJB, поэтому плохая реализация JNDI не должна позволять вам определять имена JNDI.

Я думаю, что лучшим решением является использование стороннего сопоставления JNDI или локатора служб.

...