Служба имен и каталогов JNDI
JNDI предназначен для единообразного доступа к разнообразным службам имен и каталогов, включая упомянутые выше DNS и файловую систему, а также LDAP, DataSource. Разные службы каталогов интегрируются с JNDI через интерфейс поставщика услуг SPI (Service Provider Interface).
Концепция JNDI основана на двух основных определениях :
По сути, JNDI представляет собой аналог JDBC для служб имен и каталогов. Также, как и JDBC предоставляет стандартный Java API для доступа к разнообразным базам данных, JNDI стандартизует доступ к службам имен и каталогов. На следующем рисунке представлена архитектура JNDI.
Как показано на рисунке JNDI представляет обобщенную абстракцию доступа к самым разным службам имен, таким как LDAP (Lightweight Directory Access Protocol), DNS (Domain Naming System), NIS (Network Information Service), NDS (Novell Directory Services), RMI (Remote Method Invocation), CORBA (Common Object Request Broker Architecture). Получив экземпляр контекста JNDI, его можно использовать для поиска ресурсов в любой службе имен, доступной этому контексту. За кулисами JNDI взаимодействует со всеми доступными ей службами имен, передавая им имена ресурсов, которые требуется найти и выясняя, где в действительности находится искомый ресурс.
Инициализация контекста JNDI
Чтобы воспользоваться хранящимся в контексте JNDI ресурсом, необходимо инициализировать контекст javax.naming.Context и найти требуемый ресурс. Инициализация Context’a напоминает настройку драйвера JDBC при подключении к серверу базы данных.
Чтобы подключиться к службе имен или каталогов, необходимо получить библиотеки JNDI для этой службы. Это напоминает выбор соответствующего драйвера JDBC. Если требуется подключиться к LDAP, DNS или файловой системе компьютера, необходимо получить провайдера для соответствующей службы соответственно.
При работе в окружении Java EE (WEB), сервер приложений загружает все необходимые библиотеки для доступа к окружению JNDI. В противном случае необходимо настроить свое приложение, указав, какие библиотеки JNDI оно должно использовать. Сделать это можно, например, создав объект Properties и передав его конструктору InitialContext :
В представленном примере выполняется настройка объекта Properties для доступа к дереву JNDI удаленного сервера БД Oracle. Необходимо принять во внимание, что параметры подключения к JNDI зависят от конкретного производителя и представленный пример не является универсальным. Следует обращаться к документации с описанием своего сервера приложений, чтобы узнать, как организовать удаленное подключение.
Другой способ определения настроек JNDI связан с созданием файла jndi.properties и определением пути в CLASSPATH приложения. Содержимое файла настроек представляет те же самые пары имя/значение, что помещаются в объект Properties. После этого данный файл будет использоваться автоматически при создании контекста вызовом InitialContext :
В таблице перечислены наиболее часто используемые свойства JNDI, необходимые для подключения к удаленному провайдеру службы JNDI.
Поиск ресурсов в JNDI, lookup
Метод lookup интерфейса javax.naming.Context возвращает ресурс с именем name, который следует привести к требуемому типу.
Если в аргументе name передать пустую строку, то возвращается новый экземпляр Context.
Чтобы отыскать ресурс, необходимо знать его имя. Допустим, что в JNDI компонент BidService зарегистрирован под именем “/ejb/bid/BidService”. Чтобы найти его, можно выполнить поиск непосредственно :
Пример JNDI
Широкое распространение JNDI получила при подключении к серверу БД. Пример использования JNDI для настройки подключения DataSource к серверу базы Oracle в сервере приложений JBoss рассмотрен здесь.
Ниже приведен пример, в котором используется JNDI для просмотра содержимого корня контекста DNS сервера. В примере использован открытый адрес URL сайта Yandex, размещенный в Википедии.
В результате работы программы в консоли можно увидеть следующие сообщения :
В Enterprise JavaBeans JNDI используется для нахождения всех видов ресурсов, включая компонент EJB, пул соединений с базой данных, информацию об окружении и многое другое. Таким образом, из окна контейнера EJB можно «увидеть остальной мир» посредством JNDI. Клиентское приложение также использует JNDI для получения соединения с фабрикой EJB.
Что представляет собой поставщик услуг при использовании JNDI с EJB? Ответ заключается в том, что контейнер EJB определяет свою собственную службу JNDI, специализированную для работы с ресурсами, управляемыми контейнером. Иными словами, служба JNDI в этом случае позволяет клиентам и Enterprise JavaBeans’ам находить ресурсы по JNDI именам. Следует помнить, что когда вы стартует Ваш контейнер EJB, то также неявно запускается EJB JNDI служба, которая доступна через стандартный JNDI API. О формате именования компонентов EJB подробно представлено здесь.
JNDI и приложения
Общие сведение о JNDI
JNDI предназначен для единообразного доступа к разнообразным службам имен и каталогов, включая упомянутые выше DNS и файловую систему, а также LDAP,о котором еще пойдет речь. Разные службы каталогов интегрируются с JNDI через интерфейс поставщика услуг (Service Provider Interface, SPI).
Первая редакция спецификация JNDI была выпущена корпорацией Sun Microsystems 10 марта 1997 г. В 2006 г. вышла спецификация JNDI версии 1.2. JNDI состоит из следующих пяти пакетов:
В этой главе мы рассмотрим использование JNDI для извлечения объектов из службы имен, а в следующей главе пойдет речь о доступе к LDAP.
Пример: использование JNDI для доступа к DataSource
InitialContext ctx = new InitialContext();
DataSource ds = (DataSource) ctx.lookup(«java:/DefaultDS»);
private DataSource ds;
В следующем разделе будет приведен более содержательный пример использования JNDI для доступа к LDAP каталогу, хранящему информацию о пользователях.
Общие сведения о LDAP
Информация, содержащаяся в каталоге, составляет базу данных, называемую directory information base (DIB).Элементы DIB образуют дерево, называемое directory information tree (DIT).Каждый элемент имеет имя и набор типизированных атрибутов с их значениями. Схема каталога определяет обязательные и опциональные атрибуты для каждого класса объектов каталога.
Пользователи каталога X.500 могут, с учетом прав доступа, читать и изменять объекты и их атрибуты в DIB.
Одним из самых известных и широко распространенных LDAP серверов является OpenLDAP (http://www. openldap. org/), доступный бесплатно вместе с исходными кодами. Во время работы над этой главой автор использовал сборку OpenLDAP под Windows,взятую по адресу http ://lucas.bergmans.us/hacks/openldap/.
Пример: система авторизации пользователей на основе LDAP
Центром системы станет сеансовый компонент без состояния (stateless session bean),инкапсулирующий всю работу с каталогом и имеющий следующий удаленный интерфейс с единственным методом authenticate () :
Различные приложения могут обращаться к этому EJB для проверки того, что введенные пользователем имя и пароль являются верными.
Рассмотрим реализацию этого EJB.
Теперь EJB готов к развертыванию и тестированию. Для его тестирования можно использовать такую программу:
Что такое JNDI в Java?
Введение в JNDI в Java
Архитектура JNDI в Java
В архитектуре мы заметили различные каталоги, связанные с JNDI, который состоит из API и интерфейса, известного как интерфейс поставщика услуг (SPI).
На этой диаграмме мы видим всю архитектуру JNDI, которая связана с приложением Java. Уровни четко упоминаются, что JNDI API находится выше интерфейса, и интерфейс используется для подключения ко многим каталогам. Некоторые из служб каталогов упомянуты ниже.
Вышеупомянутые каталоги, с которыми JNDI SPI интегрируется и создает платформу с возможностями реализации JNDI.
Пакеты JNDI в Java
Кроме того, JNDI играет важную роль в трех из последних технологий Java. Они есть:-
JDBC предназначен для обработки базы данных, а JMS является приложением службы сообщений. EJB работает с Netbeans и платформой Eclipse для запуска Java-программ. Пакеты присутствуют вместе с технологиями, в которых они используются.
JNDI также используется с поставщиком услуг LDAP. Существует ряд кодов, которые запускают приложение программирования на языке Java.
В языке программирования Java есть функции bind () и look up (), которые используются для именования объектов и поиска объектов из каталога.
Здесь имени можно присвоить любое имя текущему объекту в каталоге. Это пример функции связывания, в которой задано имя объекта.
Object hello= Context.lookup(“name”)
В этой функции объект hello ищет имя объекта в каталоге. Существуют также варианты сериализованных или несериализованных данных, используемых в качестве вида поддержки каталога.
JNDI и его приложения широко используются в индустрии аналитики данных, где требуется много данных, которые необходимо добывать, и есть определенный аспект хранения данных в разных каталогах, а файлы хранятся в разных папках. Он широко используется в телекоммуникационной отрасли, где производится расчет счетов в соответствии с почасовой частотой разговоров.
Пример JNDI в Java
Этот код представляет собой программу на основе меню, которая запрашивает у пользователя вводить основную сумму, а затем печатает простой процент, сложный процент и разницу между простым и сложным процентами в соответствии с потребностями пользователя. Программа также завершается, когда пользователь не хочет продолжать программу дальше. Процентная ставка установлена на уровне 8, 5%, а количество лет, необходимое для получения процентов, составляет 7 лет. Соответственно рассчитываются все процентные ставки.
Для создания программы на основе меню введите основную сумму и рассчитайте простой процент, сложный процент и абсолютную разницу между ними.
Выход:
Здесь мы вводим основную сумму в 10000 рупий и узнаем простую и сложную проценты, а также разницу.
Вывод
Рекомендуемые статьи
Что такое JNDI? Каково его основное использование? Когда это используется?
Каково его основное использование?
Когда это используется?
Каково его основное использование?
JNDI позволяет распределенным приложениям искать сервисы абстрактным, независимым от ресурсов способом.
Это имеет несколько преимуществ:
Каково его основное использование?
Большая часть описана в ответе выше, но я хотел бы представить здесь архитектуру, чтобы выше было больше смысла.
Чтобы использовать JNDI, у вас должны быть классы JNDI и один или несколько поставщиков услуг. Java 2 SDK v1.3 включает в себя трех поставщиков услуг для следующих служб именования / каталогов:
Таким образом, в основном вы создаете объекты и регистрируете их в службах каталогов, которые позже вы можете выполнять поиск и выполнять операции.
JNDI, с точки зрения непрофессионала, в основном представляет собой интерфейс для возможности получения экземпляров внутренних / внешних ресурсов, таких как
или любой другой тип, определенный адаптером ресурсов JCA. Он обеспечивает синтаксис, позволяющий создавать доступ, будь то внутренний или внешний. т.е. (comp / env в данном случае означает, что где компонент / среда, есть много другого синтаксиса):
JNDI Обзор
JNDI также определяется независимо от какой-либо конкретной реализации службы именования или службы каталогов. Это позволяет приложениям получать доступ к различным, возможно, множественным службам имен и каталогов, используя общий API. Разные провайдеры именования и службы каталогов могут быть легко подключены к этому общему API. Это позволяет приложениям, основанным на технологии Java, использовать информацию в различных существующих службах имен и каталогов, таких как LDAP, NDS, DNS и NIS (YP), а также позволяет приложениям сосуществовать с унаследованным программным обеспечением и системами.
Используя JNDI в качестве инструмента, вы можете создавать новые мощные и переносимые приложения, которые не только используют преимущества объектной модели Java, но и хорошо интегрируются в среду, в которой они развернуты.
Что такое JNDI?
JNDI расшифровывается как Java Naming and Directory Interface. Стандартно поставляется с J2EE.
Каково его основное использование?
С помощью этого API вы можете получить доступ ко многим типам данных, таким как объекты, устройства, файлы именования и службы каталогов, например. он используется EJB для поиска удаленных объектов. JNDI предназначен для обеспечения общего интерфейса для доступа к существующим службам, таким как DNS, NDS, LDAP, CORBA и RMI.
Когда это используется?
Служба именования связывает имена с объектами и находит объекты на основе их заданных имен (реестр RMI является хорошим примером службы именования.) JNDI предоставляет общий интерфейс для многих существующих служб именования, таких как LDAP, DNS.
Без JNDI информация о местоположении или доступе к удаленным ресурсам должна быть жестко задана в приложениях или сделана доступной в конфигурации. Сохранение этой информации довольно утомительно и подвержено ошибкам.
Мне просто любопытно, почему официальные документы так игнорируются, что детально прорабатывают детали.
Я буду использовать один пример, чтобы объяснить, как JNDI можно использовать для настройки базы данных, при этом ни один разработчик приложения не знает имени пользователя и пароля базы данных.
Теперь это jndi-имя и связанный с ним объект источника данных будут доступны для нашего application.application.
2) Мы можем получить этот объект источника данных, используя класс JndiDataSourceLookup.
Spring создаст экземпляр компонента источника данных после того, как мы предоставим jndi-имя.
Теперь мы можем изменить размер пула, имя пользователя или пароль в соответствии с нашей средой или требованиями, но это не повлияет на приложение.
Примечание : encryptedSecurityDomain, нам нужно настроить его отдельно на сервере JBoss, например:
Это один из вариантов использования. Надеюсь, это проясняет.
Лучшее объяснение мне дано здесь
Что такое JNDI
Проще говоря, это похоже на хэш-карту с ключом String и значениями Object, представляющими ресурсы в сети.
Какие проблемы решает JNDI?
Без JNDI информация о местоположении или доступе к удаленным ресурсам должна быть жестко задана в приложениях или сделана доступной в конфигурации. Сохранение этой информации довольно утомительно и подвержено ошибкам.
Если ресурсы были перемещены на другой сервер, например, с другим IP-адресом, все приложения, использующие этот ресурс, должны быть обновлены с помощью этой новой информации. С JNDI это не обязательно. Только соответствующая привязка ресурса должна быть обновлена. Приложения по-прежнему могут обращаться к нему по его имени, и перемещение является прозрачным.
2
Java Naming And Directory Interface
This chapter describes the Java Naming and Directory Interface (JNDI) service implemented by Oracle9 i AS Containers for J2EE (OC4J) applications. It covers the following topics:
Introduction
JNDI, part of the J2EE specification, and provides naming and directory functionality for Java applications. Because JNDI is defined independently of any specific naming or directory service implementation, it enables Java applications to access different, possibly multiple, naming and directory services using a single API. Different naming and directory service provider interfaces (SPIs) can be plugged in behind this common API to handle different naming services.
Before reading this chapter, you should be familiar with the basics of JNDI and the JNDI API. For basic information about JNDI, including tutorials and the API documentation, visit the Sun Microsystems Web site at:
Initial Context
The concept of the initial context is central to JNDI. The two most often-used JNDI operations in J2EE applications are:
When OC4J starts up, it constructs a JNDI initial context for each application by reading each of the application’s configuration XML files that can contain resource references. Applications are defined in the server.xml configuration file.
After the initial configuration, the JNDI tree for each application is purely memory-based. Additions made to the context are not persisted. When OC4J is restarted, any new bindings made in application code are no longer available.
The following example shows two lines of Java code to use on the server side in a typical Web or EJB application:
The first statement creates a new initial context object, using the default environment. The second statement looks up an EJB home interface reference in the application’s JNDI tree. In this case, myEJB might be the name of a session bean that is declared in the orion-web.xml (or web.xml ) configuration file, in an tag. For example:
This chapter focuses on setting up the initial contexts for using JNDI, and describing how OC4J performs JNDI look ups. For more information about the other JNDI classes and methods, see the Javadoc at:
Constructing a JNDI Context
When OC4J starts up, it constructs a JNDI context for each application deployed in the server (in server.xml ). There is always at least one application for an OC4J server, the global application, which is the default parent for each application in a server instance. User-written applications inherit properties from the global application. User-written applications can override property values defined in the global application, define new values for properties, and define new properties as required.
The environment that OC4J uses to construct a JNDI initial context can be found in three places:
The JNDI Environment
The JNDI InitialContext has two constructors:
The first constructor creates a Context object using the default context environment. If this constructor is used in an OC4J server-side application, the initial context is created by OC4J when the server is started, using the default environment for that application. This constructor is the one typically used in code that runs on the server side, such as in a JSP, EJB, or servlet.
The second constructor takes an environment parameter. The second form of the InitialContext constructor is normally used in client applications, where it is necessary to specify the JNDI environment. The env parameter in this constructor is a Hashtable that contains properties required by JNDI. These properties, defined in the javax.naming.Context interface, are listed in Table 2-1.
Table 2-1 InitialContext Properties
INITIAL_CONTEXT_FACTORY
Value for the java.naming.factory.initial property; this property specifies which initial context factory to use when creating a new initial context object.
Value for the java.naming.provider.url property; this property specifies the URL that the application client code uses to look up objects on the server. Also used by the RMIInitialContextFactory to search for objects in different applications.
SECURITY_PRINCIPAL
Value for the java.naming.security.principal property; this property specifies the user name. Required in application client code to authenticate the client. Not required for server-side code, because the authentication has already been done.
SECURITY_CREDENTIAL
See «Remote Client Example» for a code example that sets these properties and gets a new JNDI initial context.
Initial Context Factories
The three JNDI initial context factories available for use by application code. They are
The following sections describe each of these factories and their uses in OC4J applications.
ApplicationClientInitialContextFactory
When an application client needs to look up a resource that is available in a J2EE server application, the client uses ApplicationClientInitialContextFactory in the com.evermind.server package to construct the initial context.
When clients use the ApplicationClientInitialContextFactory to construct JNDI initial contexts, they can look up local objects (objects contained in the immediate application, or in its parent application) using the java:comp/env mechanism, and can use ORMI to look up remote objects.
Environment Properties
ApplicationClientInitialContextFactory invokes RMIInitialContextFactory to read the properties listed in Table 2-2 from the environment.
Table 2-2 JNDI-Related Environment Properties
dedicated.connection
Each JNDI lookup retrieves a connection to the server. Each subsequent JNDI lookup for this same server uses the connection returned by the first JNDI lookup. That is, all requests are forwarded over and share the same connection.
java.naming.provider.url
Multiple hosts (for failover) can be supplied in a comma-separated list.
Context.SECURITY_PRINCIPAL
The user name. Required in client-side code to authenticate the client. Not required for server-side code because authentication has already been done.
Context.SECURITY_CREDENTIAL
Remote Client Example
The following example code shows how JNDI properties can be specified in a client application:
Server-Side Clients
To look up resources that are not defined within the client application, clients must set the InitialContextFactory to RMIInitialContextFactory and look up the resources or EJB using an explicit URL.
ApplicationInitialContextFactory
When code is running in a server, it is, by definition, part of an application. Therefore, as part of an application, OC4J can establish defaults for properties that JNDI uses. For the java.naming.factory.initial property, OC4J sets ApplicationInitialContextFactory in the com.evermind.server package as the default value for this system property.
Example
As a concrete example, consider a servlet that needs to get a data source to perform a JDBC operation on a database. The data source reference is mapped in orion-web.xml as:
The data source location is specified in data-sources.xml as:
In this case, the following code in the servlet returns the correct reference to the data source object:
No initial context factory specification is necessary, because OC4J sets ApplicationInitialContextFactory as the default value of the system property java.naming.factory.initial when the application starts.
An application can use the java:comp/env mechanism to look up resources that are specified not only in its own name space, but also in the name spaces of any declared parent applications, or in the global application (which is the default parent if no specific parent application was declared).
RMIInitialContextFactory
Occasions arise for use of the RMIInitialContextFactory property in the com.evermind.server.rmi package. Using either the default server-side ApplicationInitialContextFactory or specifying ApplicationClientInitialContextFactory works for most application purposes.
In some cases, however, an additional context factory must be used:
Remote Client Example
You can use the following code to look up a remote object using RMIInitialContextFactory :
