Javaee--jndi (on, Introduction)

Ref: 50450332

Https://www.landui.com/help/show-6158.html

Https://www.cnblogs.com/zhchoutai/p/7389089.html

Jndi is a Java Naming and folder interface (Java naming and Directory Interface), one of the important specifications in the Java EE specification.

There is no jndi approach:

When the program Ape was developed, knowing to develop an application to access the MySQL database, it encoded a reference to the MySQL JDBC driver class and connected to the database by using the appropriate JDBC URL.
Just like the following code:

1Connection conn=NULL; 2 Try {  3Class.forName ("Com.mysql.jdbc.Driver",  4                 true, Thread.CurrentThread (). Getcontextclassloader ()); 5conn=DriverManager. 6Getconnection ("Jdbc:mysql://mydbserver?user=qingfeng&password=mingyue"); 7   ......  8 Conn.close (); 9}Catch(Exception e) {Ten E.printstacktrace ();  One}finally {   A   if(conn!=NULL) {   -     Try {   - Conn.close ();  the}Catch(SQLException e) {} -   }   -}

This is the traditional practice, but also once non-Java program Ape (such as Delphi, VB, etc.) common practice.

This approach generally does not create problems in small-scale development processes, only the program ape familiar with the Java language, understanding JDBC technology and MySQL, can very quickly develop the corresponding application.

There is a problem with the practice of Jndi:
1, the database server name MyDBServer, username and password may need to change, resulting in the JDBC URL needs to be changed;
2, the database may switch to another product, such as the use of DB2 or Oracle, triggering the JDBC driver package and the class name need to change;
3, with the actual use of terminal additions, the original configuration of the connection pool may need to adjust the number of parameters;
4 、......

The workaround:
Program apes should not care "what is the detailed database background?" What is the JDBC driver? What is the JDBC URL format? What is the username and password for the database? "And so on these questions. Program apes should not have a reference to the JDBC driver, no server name, no real username or password--not even a database pool or connection management.

Instead, these questions are given to the Java EE container (for example, WebLogic) for configuration and management, and the program apes simply need to reference these configurations and management.

Thus, there is the Jndi.

To see it. is for the most central problem: to understand the decoupling, is to develop a more maintainable, extensible//System

Use the following Jndi approach:
First of all. Configure the Jndi parameters in the Java EE container to define a data source. This is the JDBC reference parameter, which sets a name for the data source, and then, in the program, references the data source through the data source name to access the backend database.

In the Java EE specification, resources in the Java EE are not limited to JDBC data sources.

There are very many types of references, including resource references (discussed already), environment entities, and EJB references.

In particular, EJB references, which expose another key role of JNDI in the Java EE: Find other application components.

The JNDI reference of an EJB is very similar to a reference to a JDBC resource. In an environment where services tend to be transformed, this is a very effective approach. This kind of configuration management can be done on all the components in the application architecture, from EJB components to JMS queues and topics. To a simple configuration string or other object. This reduces maintenance costs resulting from service changes over time, simplifying deployment at the same time, and reducing integration efforts. External resources ".

Summarize:
The Java EE specification requires that all Java EE containers provide the implementation of the JNDI specification. Sun did like it. The role of the canonical Jndi in the Java EE is the general mechanism for the "switch"--J2EE component to find other components, resources, or services at execution time grounding. In most cases, a container that provides a JNDI provider can act as a limited data store. This allows the administrator to set the execution properties of the application and to have other applications reference those properties (Java Management extensions,jmx) can also be used for this purpose. The primary role of JNDI in the Java EE application is to provide an indirection layer so that the component can discover the resources it needs without knowing the indirection.

In Java EE, JNDI is the glue that fits the Java EE application together. The indirection provided by JNDI agrees to deliver scalable, powerful, and very flexible applications across the enterprise.

This is the promise of the Java EE and has been planned and pre-considered. This commitment is fully achievable.


As can be seen from the above article:
1, the purpose of JNDI is to understand Lotus root, is to develop easier maintenance, easy expansion. Easy to deploy apps.
2, JNDI is a Sun proposed specification (similar to JDBC), the detailed implementation is the various Java EE container provider. Sun simply requires that the Java EE container must have JNDI functionality.

3. The role of JNDI in the Java EE system is "switch", which is a general mechanism for the Java EE component to find other components, resources or services in execution time grounding.
4. JNDI is found by the name of the resource, and the name of the resource is unique throughout the Java EE application (the Java EE container).

Javaee--jndi (on, Introduction)