Your application can easily establish a connection to this new established data source with the following code.

SessionFactory sessions = cfg.buildSessionFactory();
Session session = sessions.openSession();

Spring Framework
The Spring Framework is a relatively recent innovation, but it already enjoys significant developer support for a variety of reasons. It addresses some of the core complaints associated with working with J2EE by absolving and abstracting the developer from the intricacies of J2EE. Spring's layered architecture is modularized, which permits you to select the components that best meets the application requirements. As described in this article, you can leverage the JDBC capabilities provided by Spring while ignoring the other layers it provides.

If you are considering O/R persistence on top of JDBC, the Spring Framework Data Access Objects (DAO) deserves a close look. The DAO consistent layer allows you to gracefully assemble object persistence directly on top of JDBC, Hibernate, or even Oracle TopLink. Spring's concept of DAO is grounded on the principle of Plain Old Java Objects, often referred to as POJOs. POJOs allow you to think in terms of Java objects while allowing the underlying persistence mechanisms to manage the application object life cycle.

Spring's DAO architecture has carefully considered JDBC and has delivered an alternative to the native JDBC that some consider difficult to manage. Particular emphasis has been given to improving error handling when dealing with underlying relational data sources, as significant improvements have been made with respect to the depth of exceptions that can be reported against any data source. These efforts have not gone unnoticed by the JDBC specification team as they are quietly being adopted in the JDBC 4.0 exception hierarchy.

The Spring Framework provides JDBC abstraction using four packages that provide the core data source object and associated support. As with any modern coding practice, Spring requires you to follow a set of design patterns. In this case, bean definition files, written in XML, are used extensively and are the primary way to configure applications using Spring.

In the following example, we use a bean definition file to configure a J2EE DataSource using JDBC DriverManager class:

<beans>
<bean id="myDataSource"
class="org.apache.commons.dbcp.BasicDataSource"
destroy-method="close">
<property name="driverClassName"
value="com.ddtek.jdbc.sqlserver.SQLServerDriver" />
<property name="url"
value="jdbc:datadirect:sqlserver://<HOST>/mydb"/>
<property name="sa" value="sa" />
</bean>
:
</beans>

We can also do this using a JDBC programmatic approach:

DriverManagerDataSource dataSource = new DriverManagerDataSource();
dataSource.setDriverClassName("com.ddtek.jdbc.sqlserver.SQLServerDriver");
dataSource.setUrl("jdbc:datadirect:sqlserver://<HOST>:/test");
dataSource.setUsername( "sa" );
dataSource.setPassword( "sa" );

With Spring, it is possible to layer the DAO layer on top of JDBC or an O/R Persistence mechanism such as Hibernate. Building Spring-enabled applications with Hibernate is an increasingly popular model since developers can realize increased productivity gains. With Spring's modular and layered approach, you can easily mix and match your preferred approach to data access. Spring provides JdbcDaoSupport, HibernateDaoSupport, and JdoDaoSupport classes for use of their DAO model on top of either the data access or persistence layer.

Standards Based: EJB 3.0
EJB 3.0
EJB 3.0 is a standard-based effort that has been underway since the launch of a number of JSRs sponsored by Sun Microsystems that are aimed at simplifying the J2EE platform. EJB 3.0 was originally focused on resolving many of the difficulties developers experienced with session beans and message-driven beans (MDB). Although not a foundational goal, the EJB 3.0 expert group felt it was important to establish a consistent persistence layer in EJB in an effort to quell ongoing debates about the J2EE's standard persistence model. By soliciting input directly from the O/R Mapping industry, EJB 3.0 has evolved significantly from its original specification goals. At the time of writing, EJB 3.0 Public Review draft provides a unifying Persistence layer that is the result of cooperative efforts from lead developers of Hibernate, JDO, Oracle TopLink, and others that have a vested interest in this space.

This cooperative effort is excellent news for developers and architects alike since EJB 3.0 promises to combine the best design efforts of Hibernate, JDO, and Oracle TopLink. This effort will result in the delivery of an O/R model that will become the standard for future J2EE-based development. Furthermore, EJB 3.0's persistence layer specification will be immediately recognizable to anyone who has previously worked with the established O/R mapping mechanisms. The concept of the EntityManager is almost identical to a similar idea provided by Hibernate. And, the provision of Named queries, Callback listeners, and O/R Mapping types have all been heavily influenced by the existing O/R persistence market leaders.