J2EE Without the Application Server

Step 2: Configuring the BankDAO

We will use the Spring framework to configure our application. Spring is not strictly necessary, but the advantage of using it is that we will be able to declaratively add services like transactions and security to our Java objects. This is similar to what the application server allows for EJB, only in our case it is going to be a lot easier. Spring also allows us to decouple our classes from the actual JDBC driver implementation: it is the Spring utility that will configure the driver (based on our XML configuration data) and supply it to the BankDAO object (the dependency injection principle). This keeps our Java code clean and focused. The Spring configuration file for this step is shown next.

<?xml version="1.0" encoding="UTF-8"?>

<!DOCTYPE beans PUBLIC "-//SPRING//DTD BEAN//EN" 

"http://www.springframework.org

/dtd/spring-beans.dtd">



<beans>



<bean id="datasource" 

class="com.atomikos.jdbc.nonxa.NonXADataSourceBean">



    <property name="user">

        <value>sa</value>

    </property>

    <property name="url">

        <value>jdbc:hsqldb:SpringNonXADB

        </value>

    </property>

    <property name="driverClassName">

        <value>org.hsqldb.jdbcDriver</value>

    </property>

    <property name="poolSize">

        <value>1</value>

    </property>

    <property name="connectionTimeout">

        <value>60</value>

    </property>

</bean>



<bean id="bank" class="jdbc.Bank">

        <property name="dataSource">

            <ref bean="datasource"/>

        </property>

</bean>



</beans>

This XML file contains the configuration settings for two objects: the DataSource needed to access the database and the Bank object that uses this datasource. The following are some fundamental tasks taken care of by Spring:

• Creation of objects ("beans") needed by the application (i.e., the bank and the datasource). The class names for these objects are given in the XML file, and in our case they need to have a public no-argument constructor (Spring also allows for constructor arguments, but that requires a slightly different XML syntax). The objects are named (via the id attribute in XML) so we can refer to them later. The id also allows our application to retrieve the configured objects it needs.
• Initialization of these objects is via properties whose values are supplied in XML. The property names in the XML file should correspond to a setXXX method in the referred class.
• Linking objects together: a property can be a reference to another object (such as the datasource, in our example). References are made by id.

Note that in anticipation of our next step, we have chosen to configure a JTA-enabled datasource (supplied by Atomikos Transactions, the enterprise-capable and J2SE-compatible JTA product we will use for our application). For simplicity of the demo, the underlying DBMS is HypersonicSQLDB, which does not require any special installation steps--it runs from within its .jar file just like the JTA and Spring. However, for increased reliability, it is strongly recommended that you use an XA-capable DBMS and JDBC drivers. Without XA, your application will not be recoverable after a crash or restart. Check out the Resources section for a link to more information on transactions and XA, and in which cases you need them. As a practical exercise, you could try to switch HypersonicSQLDB to FirstSQL, an easy-to-install, XA-compliant DBMS. Alternatively, any other enterprise-ready and XA-capable DBMS will do as well.