下面的英文是我找过来的，因为是英文所以不敢翻译出来误导别人，但是它描述的确实恰到好处，比所谓网上的JNDI和JDBC云云的解释要精辟很多，如果遇到不认识的单词，用有道吧~~：)
The Java Naming and Directory Interface (JNDI) is an application programming interface (API) for accessing different kinds of naming and directory services. JNDI is not specific to a particular naming or directory service, it can be used to access many different kinds of systems including file systems; distributed objects systems like CORBA, Java RMI, and EJB; and directory services like LDAP, Novell NetWare, and NIS+.
JNDI is similar to JDBC in that they are both Object-Oriented Java APIs that provide a common abstraction for accessing services from different vendors. While JDBC can be used to access a variety of relational databases, JNDI can be used to access a variety of of naming and directory services. Using one API to access many different brands of a service is possible because both JDBC and JNDI subscribe to the same architectural tenet: Define a common abstraction that most vendors can implement. The common abstraction is the API. It provides an objectified view of a service while hiding the details specific to any brand of service. The implementation is provided by the vendor, it plugs into the API and implements code specific to accessing that vendor's product.
JNDI provides two APIs and one SPI. JNDI has a naming API that allows Java applications to access naming systems like CORBA's Naming services and a directory API that extends the naming service to provide access to directory services like LDAP. JNDI also has a SPI (Service-Provider Interface) which is a programming model that vendors use to write JNDI plug-ins or implementations for their specific product. Each vendor's plug-in is called a service-provider. A service-provider implements the JNDI APIs so that a Java application can access that vendor's product. For the most part, JNDI hides the implementation details of the a service-provider so that Java developer that uses JNDI can use the same objects and method regardless of the brand of naming or directory service accessed. This is the real power behind APIs like JDBC and JNDI: They provide one programming model for accessing many different products; there is no need to learn a different programming model every time a different product is used.
我的理解：JDBC和JNDI的对比认识
JDBC和JNDI都是一种规范，是一组统一的API，里面包含了一组接口规范要求服务提供商来实现，包含了一组应用规范供编程人员使用，这样的好处是有利于编程人员可以用同一种方式来访问不同的数据库，使用同一种方式来方式来访问命名和目录服务，这里的同一种方式就是JDBC和JNDI提供的API，比如JDBC中的Connection等，JNDI中的Context等，并不是连接数据库或者使用命名和目录服务的方式对于各个数据库管理系统或者命名和目录服务提供者来说都是一样的，只是JDBC和JNDI提供另外的接口规范要求这些提供商来实现，比如各个数据库系统提供的驱动jar包，tomcat和JBoss容器各自配置Resouce的方式等，也就是说对编程人员隐藏了具体连接数据库或访问命名和目录服务的细节，让编程人员只需要关注自己的开发，即使后面换了数据库系统，换了web服务器等，应用程序依然不需要改变，只需要改变JDBC和JNDI的实现，这正是java平台无关性的表现~
对JDBC来说，要使用的服务只有：连接并与数据库交互。所以JDBC不论理解还是使用都是比较简单。
对JNDI来说，可供使用的服务包括命名和目录服务，命名服务允许编程人员通过名称查找对象，目录服务是命名服务的扩展，目录服务中的对象不单有名称还有属性，也就是可以利用属性来查找对象。而且命名和目录服务种类并不唯一：DNS、XNam 、Novell目录服务、LDAP、 CORBA对象服务、文件系统、Windows XP/2000/NT/Me/9x的注册表、RMI、DSML v1&v2、NIS。所以JNDI比JDBC要复杂蛮多。网上见过的最多的关于JNDI的使用例子，就是tomcat或者Jboss容器配置数据源，然后应用程序通过JNDI命名服务查找数据源，这也许是最典型的应用了。
什么是命名服务？
命名服务在一个集中位置存储信息，这样用户、计算机和应用程序便可通过网络进行通信。命名服务使用名称查找对象，而不是对象的物理ID。比如说在tomcat中查找JDBC数据源不是通过数据源的直接引用查找，而是通过JNDI与数据源绑定的名称查找，比如说通过DNS可以使用域名来访问Web应用，而不是直接通过输入Web服务器的IP地址来访问，这里的数据源的引用和IP地址都可以看作是资源的物理ID。命名服务有DNS，NIS，LDAP等。DNS称为域名系统，开发 DNS 后，网络中的计算机可由通用名称而非 Internet （IP）地址来标识。NIS称为网络信息服务，NIS 的主要作用是通过对各种网络信息进行集中控制来更好地管理网络。NIS 存储有关网络、计算机名称和地址、用户、以及网络服务的信息。LDAP还没去了解。
什么是目录服务？
目录服务是命名服务的扩展，目录服务的对象不单有名称，还有属性，既可以通过名称查找对象，也可以通过属性查找到一批对象然后筛选出自己需要的对象。目录服务应该比命名服务更广发，它可以将整个网络中的资源和设备组织起来，形成一个大的目录，然后通过目录就可以定位资源和设备，实现集中管理。
tomcat或Jboss的数据源属于什么服务？
属于命名服务，因为tomcat和Jbosss容器提供了命名服务或者目录服务，然后编程人员想用使用它们的服务时假如没有JNDI则必须遵照它们定的规范来开发，显然两个容器的使用服务的方法是不一样的，所以才有JNDI的规范。也就是说命名和目录服务并不是因为编程而存在的，而是Web容器本身就具有的。
转自：