DataSource interfaces were designed to allow additional flexibility in using Java™ Database Connectivity (JDBC) drivers.
The use of DataSources can be split into two phases:
Deployment is a setup phase that occurs before a JDBC application actually runs. Deployment usually involves setting up a DataSource to have specific properties and then binding it into a directory service through the use of the Java Naming and Directory Interface (JNDI). The directory service is most commonly the Lightweight Directory Access Protocol (LDAP), but could be a number of others such as Common Object Request Broker Architecture (CORBA) Object Services, Java Remote Method Invocation (RMI), or the underlying file system.
By decoupling the deployment from the runtime use of the DataSource, the DataSource setup can be reused by many applications. By changing some aspect of the deployment, all the applications that use that DataSource automatically pick up the changes.
The UDBDataSourceBind program is an example of creating a UDBDataSource and getting it bound with JNDI. This program accomplishes all the basic tasks requested. Namely, it instantiates a UDBDataSource object, sets properties on this object, retrieves a JNDI context, and binds the object to a name within the JNDI context.
The deployment time code is vendor-specific. The application must import the specific DataSource implementation that it wants to work with. In the import list, the package-qualified UDBDataSource class is imported. The most unfamiliar part of this application is the work done with JNDI (for example, the retrieval of the Context object and the call to bind). For additional information, see JNDI by Sun Microsystems, Inc.
Once this program has been run and has successfully completed, there is a new entry in a JNDI directory service called SimpleDS. This entry is at the location specified by the JNDI context. The DataSource implementation is now deployed. An application program can make use of this DataSource to retrieve database connections and JDBC-related work.
The UDBDataSourceUse program is an example of a JDBC application that uses the previously deployed application.
The JDBC application obtains an initial context as it did before binding the UDBDataSource in the previous example. The lookup method is then used on that context to return an object of type DataSource for the application to use.
Suppose that UDBDataSourceUse is a complex application that runs a large operation within your organization. You have a dozen or more similar large applications within your organization. You have to change the name of one of the systems in your network. By running a deployment tool and changing a single UDBDataSource property, you would be able to get this new behavior in all your applications without changing the code for them. One of the benefits of DataSources is that they allow you to consolidate system setup information. Another major benefit is that they allow drivers to implement functionality invisible to the application such as connection pooling, statement pooling and support for distributed transactions.
After analyzing UDBDataSourceBind and UDBDataSourceUse closely, you may have wondered how the DataSource object knew what to do. There is no code to specify a system, a user ID, or a password in either of these programs. The UDBDataSource class has defaults values for all properties; by default, it connects to the local iSeries™ server with the user profile and password of the running application. If you wanted to ensure that the connection was made with the user profile cujo instead, you could have accomplished this in two ways:
There are a number of properties that can be specified for the UDBDataSource as there are properties that can be specified for connections created with the DriverManager. Refer to DataSource properties for a list of supported properties for the native JDBC driver.
While these lists are similar, it is not certain to be similar in future releases. You are encouraged to start coding to the DataSource interface.