Java Naming and Directory Interface Java Naming and Directory Interface (JNDI) provides an interface for accessing name and directory services, such as LDAP directory services and Domain Name Service (DNS). JNDI enables Java programs to use name servers and directory servers to look up objects or data by name. This important feature enables a client object to locate a remote server object or data. JNDI is a generic API that can work with any name or directory server. As such, JNDI was not designed to replace existing technology, but instead it provides a common interface to existing naming services. For example, JNDI provides methods to bind a name to an object, enabling that object to be located, regardless of its location on the network. Server providers have been implemented for many common protocols (e.g., NIS, LDAP, and NDS) and for CORBA object registries. Of particular interest to users of J2EE, JNDI is used to locate Enterprise JavaBean (EJB) components on the network. Again, the thrust of J2EE technology is to provide enterprise application developers with much-needed services in the distributed realm. It s hard to think of a more valuable service than a naming service. JNDI provides the Java application developer with this much-needed service. Java Database Connectivity Java Database Connectivity (JDBC) provides the J2EE application a standard interface to databases (usually relational databases). In principle, JDBC serves the same purpose as Open Database Connectivity (ODBC). JDBC provides a database-independent protocol for accessing relational databases from Java. JDBC supports Data Manipulation Language (DML) statements such as insert, update, delete, and select. It also includes Data Definition Language (DDL) statements such as Create Table, Alter Table, and so on. Database vendors usually provide a JDBC driver that enables a Java program to access the vendor s RDBMS product. As of this writing, Sun has 154 JDBC drivers listed in its driver database Note See http://industry.java.sun.com/products/jdbc/drivers for a listing of available drivers for use with JDBC. JDBC was included in core Java starting with version 1.1. With JDBC, the SQL is always dynamically generated at runtime and sent to the database. Many have griped about the inefficiencies of applying dynamically created SQL against databases. In response, another standard for Java database access has emerged and is called SQLJ. SQLJ enables static SQL to be used and it requires less cumbersome syntax than JDBC. One SQLJ advantage over JDBC is better code quality because SQL is checked at compile-time. Also, SQLJ usually shows better performance than JDBC because access paths to the database are generated once and reused for subsequent executions of the static SQL. We speak of levels for JDBC drivers; the slowest are level 1 drivers and the quickest are level 4 drivers. In addition, some drivers serve as a bridge between JDBC and ODBC, mostly as an easy way to access ODBC databases (MSsomething or other databases, usually). A type 1 driver provides JDBC access using a JDBC-ODBC bridge. This bridge provides JDBC access to most ODBC drivers. Disadvantages of this type of JDBC driver include additional performance overhead of the ODBC layer, and the requirement to load client code on each client machine. A type 2 driver is a partial Java driver that converts JDBC calls into the native client database API. As with the type 1 driver, this driver requires some client code to be loaded on each client machine. A type 3 driver is a pure Java driver that translates JDBC calls into a database-independent network protocol. The database-independent protocol is implemented using a middleware server. The middleware server translates the database-independent protocol into the native database server protocol. Middleware vendors typically offer a type 3
We will hook you up with a JSP web hosting at the great rate, check our jsp web hosting, and join us today!!!