有关数据源的问题，搞掂你，shit!!!

来源：http://topic.csdn.net/u/20090510/14/5c119994-b911-4419-aea4-accf1d316eec.html      

    数据源在JDBC中的应用简介众所周知，JDBC（Java数据库连接）是Java 2企业版的重要组成部分。
它是基于SQL层的API。通过把SQL语句嵌入JDBC接口的方法中，用户可以通过Java程序执行几乎所有的数据库操作。
JDBC只提供了接口，具体的类的实现要求数据库的设计者完成。
通过生成这些接口的实例，即使对于不同的数据库，Java程序也可以正确地执行SQL调用。

所以对于程序员来说，不必把注意力放在如何向数据库发送SQL指令，因为程序员需要了解和用到的只是JDBC的接口，只有在极少数情况下会用到面向特定数据库的类，例如程序员希望使用ORACLE的扩展API。
在JDBC程序中，首先需要做的是实现与数据库的连接。
在示例程序中，我们使用的是ORACLE8i的JDBC包。连接数据库通常需要实现以下几个步骤：
1. 注册数据库驱动程序（driver）。可以通过调用java.sql.DriverManager类的registerDriver方法显式注册驱动程序，也可以通过加载数据库驱动程序类隐式注册驱动程序。
2． 建立连接。调用java.sql.DriverManager类的getConnection（）方法可以建立与数据库的连接。

从实际应用的角度出发，我们可以看出采取这种方式连接到数据库存在几个问题。
第一是安全性问题，由于程序代码中包含用户名和密码，其他人如果能得到bytecode，可以通过反编译工具获得用户名和密码。第二是代码的可移植性问题。如果希望连接的数据库名称或用户名有所更改，程序员需要修改源程序，然后把修改过的程序发送给用户。也就是说，软件无法脱离数据库独立存在。这样不仅会大大提高软件的成本，也不利于软件本身的发展。还可能出现这样的情况：在某些情况下，提供数据的机构不希望数据库的用户名和密码让编写程序的程序员知道知道。
这样就提出了一个问题，如何使Java和数据库之间建立连接时隐藏一些敏感的信息。

数据源（Data Source）及JNDI数据源是在JDBC 2.0中引入的一个概念。
在JDBC 2.0扩展包中定义了javax.sql.DataSource接口来描述这个概念。
如果用户希望建立一个数据库连接，通过查询在JNDI服务中的数据源，可以从数据源中获取相应的数据库连接。
这样用户就只需要提供一个逻辑名称（Logic Name），而不是数据库登录的具体细节。
在这里有必要简单介绍一下JNDI。JNDI的全称是Java Naming and Directory Interface， 可以理解为Java名称和目录服务接口。JNDI向应用程序提供了一个查询和使用远程服务的机制。这些服务可以是任何企业服务。对于JDBC应用程序来说，JNDI提供的是数据库连接服务。当然JNDI也可以向数据库提供其他服务，但是这超出了本文范围，在此不做论述。其实JNDI并不难理解。简单来说，名称服务提供了一个把文件，打印机，服务器等实体映射到一个逻辑名称的机制。例如在操作系统中的名称服务就把打印机映射到一个I/O端口。而目录服务可以理解为名称服务的一个扩展，它允许在服务中的各项拥有自己的属性。又以打印机为例，打印机可以是彩色打印机，支持双面打印，支持网络打印，支持高速打印等。所有这些打印机的属性都可以储存在目录服务中，和相应的打印机联系起来。一些常见的目录服务有NIS，NIS+，LDAP和Novell的NDS等。JNDI使应用程序通过使用逻辑名称获取对象和对象提供的服务，从而使程序员可以避免使用与提供对象的机构有关联的代码。例如在下面的例子中使用了在JNDI中的数据源，程序员就不需要提供Oracle8i驱动程序的名称，这样代码的移植能力就更强。
下面详细介绍一下数据源和javax.sql.DataSource接口。
在数据源中存储了所有建立数据库连接的信息。就象通过指定文件名你可以在文件系统中找到文件一样，通过提供正确的数据源名称，你可以找到相应的数据库连接。javax.sql.DataSource接口定义了如何实现数据源。
在该接口中定义了九个属性。
dataSourceName String 数据源接口实现类的名称。
description String 对数据源的描述。
networkProtocol String 和服务器通讯使用的网络协议名。
password String 用户登录密码。
portNumber Int 数据库服务器使用的端口，缺省值为1521。
serverName String 数据库服务器名称。
user String 用户登录名。

在javax.sql.DataSource接口中定义了很多方法通过这些方法，程序员可以获得建立连接需要的所有信息。
需要注意的是，程序员不可以获取登陆密码，这就在一定程度上保证了安全性。需要注意的另一点是所有的方法都是synchronized方法，这是为了保证应用程序的线程安全（Thread-safe）。
如果在调用该方法时，即使数据源实例发生变化不会影响程序的正确运行。
然后通过该数据源对象进行数据库操作。在这个例子中，程序和名称服务环境都是在同一台计算机上运行。
在实际的应用中，程序可以通过RMI或CORBA向名称服务环境注册或查询对象。例如在一个服务器-客户机结构中,客户机上的应用程序只需要知道数据源对象在服务器名称服务环境中的逻辑名称,就可以通过RMI向服务器查询数据源,然后通过建立与数据库的连接.这样就可以解决本文最开始提出的问题。

*******************************************************************

******************************************************************

以下是两一个论坛的解答：http://topic.csdn.net/u/20080713/00/c2a3e36d-d692-4343-9428-8b8f25d3ebe7.html

     主要是方便管理
1 你肯定要链接数据库
2 那么你肯定要用户名和密码
3 正式的数据库和应用服务器应该是单独的人员管理，而不是开发人员
4 密码会定期修改
5 如果链接数据库是各自书写代码和配置，则运行环境的密码修改将会是一个噩梦，一不小心就忘记一个
6 所以，大家全部到一个数据源那里获取连接。管理员只需要修改数据源的配置，而无需修改应用的配置
7 如果数据库的地址变更，则同样不会影响到应用，也只是修改数据源
8 开发人员无需知道正式数据库的密码

 

 

1 在java程序中必须要配置下数据源 因为你的web容器里必须加载你的数据源。（可以是全局的，也可以是单独的数据源）
2 数据源创建成功侯其实也就成为了一个连接池，他可以很方便的关类web用户访问数据库的连接问题。不过也有他自己的缺点。
3 比如还有的报表工具的时候，他也需要配置数据源，来获得数据库的连接。

 

 

在控制面板那里配置数据源是采用 ODBC 的方式，这种是 JDBC 驱动程序的第一种类型。
这种驱动的方式是通过 ODBC 驱动程序与数据库打交道，而我们在 Java 程序中再使用
JDBC/ODBC 桥是将 JDBC 程序翻译成 ODBC 认识的东西。

ODBC 数据源的方式是一种很古老的方式，速度不用去说了（因为通过桥的转换），现在
一般很少使用了。当然了，如果某个数据库没有提供 JDBC 驱动程序，而只提供了 ODBC
驱动的话，那还是可以使用这种方式的，比如 Access。

而后面说到的在 web.xml 中配置的数据源与之前的 ODBC 数据源不是同一个概念，前者
是 JDBC 规范中的接口，全称为 javax.sql.DataSource，而后者可以称之为一种 ODBC 驱
动程序。

据 JDBC 规范所称，DataSource 是获得数据库连接对象 Connection 的首选方法，因为
DataSource 一般都绑定在 JNDI 上，在代码中只通过 JNDI 的名称就可以获得该对这个对
象，并且通过这个对象可以直接获得数据库连接。而这个名字就是在 web.xml 中配置的
<res-ref-name> 中的名字，web.xml 中只是引用一下资源，在服务器上还得配置具体的参
数，如 Tomcat 中是在 server.xml 中配置一下。这个 DataSource 是由 JDBC 驱动实现
者实现的，在 Tomcat 中是使用 JNDI 来进行管理的，可以对其进行具体的配置，比如：
连接池的最大、最小数量、超时时间等参数，这些是由 Tomcat 来管理的。

DataSource 可以绑定在 JNDI 中只是一种方式，它还可以用于连接池的实现，比如：在
C3P0 中也实现并扩展了 DataSource，用于管理数据库的连接对象。实际上 Tomcat JNDI
上的数据源在内部也是采用 DBCP 的 DataSource 实现的。

DataSource 在 JDBC 2.0 规范中作为可选的，在 3.0 中正式地纳入到 JDBC 规范中，下面
这个是 JDBC 4.0 规范的下载地址，里面对 DataSource 有详细的描述，有兴趣的话可以去
看看：

http://jcp.org/aboutJava/communityprocess/final/jsr221/index.html