Putting it all together - iBATIS in Action - page 321

Because the service layer needs to call the data access layer and handle transac-
tion demarcation, it would be easy to simply retrieve a database connection and
manage the transaction demarcation with the database connection. But if we did
this, we'd introduce a JDBC -specific semantic into our service layer. This means
that the service layer would now be aware of the data-store implementation we are
using. As soon as our service layer becomes aware of the type of data store we are
using, we compromise its purpose.
As you learned in chapter 10, i BATIS provides a small framework called i BATIS
DAO that will be of use to us here. i BATIS DAO will fill a couple of important
responsibilities. First, it will be our data access object factory. Second, we will use the
i BATIS DAO for transaction demarcation, thus reducing the dependency our ser-
vice layer has on the underlying data access technology. In this section, we con-
tinue with our previous example and you'll learn how to set up our service layer
using i BATIS DAO .

14.7.1 Configuring dao.xml

Unlike with our presentation layer, we will start our exploration of the service
layer by first configuring the i BATIS DAO framework. This makes it easier for us to
understand the components involved in the service layer. The i BATIS DAO frame-
work allows us to manage the necessary abstraction through configuration, so it is
appropriate to start here.
The first component to configure in the i BATIS DAO is the transaction man-
ager (see listing 14.12). The transaction manager is used to handle transaction
demarcation over calls to the data access layer. In our example, we will use a trans-
action manager type of SQLMAP ; this is the type that integrates with the i BATIS
SQLMap framework. Even though it may be difficult to distinguish i BATIS DAO from
i BATIS SQLMap , they are indeed different frameworks. The SQLMAP transaction
manager is a nice and easy route to go. Unless you are using the i BATIS DAO
framework in conjunction with another persistence layer, SQLMAP is the best
transaction manager to use for most occasions. The only property that needs to be
specified for the SQLMAP transaction manager is SqlMapConfigResource , which is
specified using the <property> tag in the body of the <transactionManager> tag.
The value of the SqlMapConfigResources property simply points to the sql-map-
config file that will contain all the necessary connection configuration informa-
tion. Whenever calls are made to start, commit, and end transactions, they will
transparently make the necessary calls against the hidden connection object spec-
ified in the SQLMap configuration file.