In the industry, various methods are available to store information.
To name a few; relational databases, object-oriented databases, flat files,
Lightweight Directory Access Protocol (LDAP) repositories, XML repository etc.
Furthermore, there are multiple ways to access the data stored on these various
persistent types. Access varies greatly depending on the type of storage and
the vendor implementation. There are marked differences in the APIs and the
mechanism used to access them.
Systems that rely on specific features of underlying resources,
such as a particular vendor's database, tie together business logic and data
access mechanisms. The result is often limited portability and undesirable vendor
lock-in. As these underlying products become obsolete, or as superior solutions
appear, systems tied to older versions of products can be difficult to upgrade
or replatform. And enterprise bean component vendors want to avoid tying their
business logic components to a particular vendor, so they can serve the broadest
possible segment of the market.
The solution to the above mentioned design issue is to
use the Data Access Object (DAO) to abstract and encapsulate all access to the
data source. The DAO manages the connection with the data source to obtain and
store data.
The DAO implements the access mechanism required to work
with the data source. The data source could be a persistent store like an RDBMS,
an external service like a B2B exchange, a repository like an LDAP database,
or a business service accessed via CORBA Internet Inter-ORB Protocol (IIOP)
or low-level sockets. The business component that relies on the DAO uses the
simpler interface exposed by the DAO for its clients. The DAO completely hides
the data source implementation details from its clients. Because the interface
exposed by the DAO to clients does not change when the underlying data source
implementation changes, this pattern allows the DAO to adapt to different storage
schemes without affecting its clients or business components. Essentially, the
DAO acts as an adapter between the component and the data source.
There are two implementations of this design pattern; namely
the Abstract Factory and Factory Method patterns. When
the underlying storage is not subject to change from one implementation
to another, the DAO strategy can be implemented using the Factory Method
pattern to produce a number of DAOs needed by the application. When the
underlying storage is subject to change from one implementation to another,
DAO may be implemented using the Abstract Factory pattern. The Abstract
Factory can in turn build on and use the Factory Method implementation. A typical
DAO implementation requires the following components.
A DAO factory class: Application's use DAO
factory class to retrieve the object that implements the DAO interface.
A DAO interface: DAO interface defines the
DAO API. The methods in the interface make no reference to a specific data
access mechanism.
A concrete classthat implements the DAO
interface: The concrete DAO class contains logic for accessing data from
a specific data source. There can be more than one concrete classes depending
on the number of DAO implementations provided.
Data transfer objects (also called value objects):
Data access objects in their most basic form use transfer objects to transport
data to and from their clients.
A Business logic bean: The business logic
bean will generally contain the business logic of the application and will
call DAO implementing concrete class for database related operations. The
business logic bean is an optional object in DAO implementation. In simple
applications the database related operations can be accessed directly via
the DAO implementing concrete class.
Application Overview
This application demonstrates the implementation of Data Access
Object design pattern using the strategy of a Factory Method pattern. The scenario
where this design pattern is being implemented is a web based News Application.
When the user accesses this News application he or she can view News information
based on a News category (like Sports, Stocks, Weather etc.) or the News date.
Here the persistent News data is stored in two different type of data stores.
One of the data store is the RDBMS where the News information is stored in a
relational table News. The second data store is XML based database where
the News information is stored in an XMLType table NewsXDB. Thus we provide
two DAO implementation to fetch News from these data-stores. NewsOracleImpl
class has methods to fetch news that is stored in RDBMS table and NewsOracleXMLDBImpl
has methods to fetch news that is stored in XMLDB table in an XMLType column.
The DAO implementation class to be used is configurable in a properties file.
The following class diagram shows the important classes in the
DAO pattern.
All DAO implementation classes should implement the NewsDAO
interface.
The following sequence diagram depicts the interactions within
the sample application (for an operation) when the DAO Implementation class
is NewsDAOOracleImpl. This fetches the news data from the relational
table.
The following sequence diagram depicts the interactions
when the DAO Implementation class is NewsDAOOracleXMLDBImpl. This
fetches the news data from the XMLDB table.
The application uses a DAO factory named NewsDAOFactory.
This provides the DAO implementation class. The object returned is selected
on the value specified by the client in the properties (configuration) file.
It returns NewsDAOOracleImpl class if the client wants data retrieval
from RDBMS data-store and returns NewsDAOOracleXMLDBImpl class
if the client wants data retrieval from XML DB data-store.
NewsDAO is the interface that defines
the DAO methods for news persistent object. The interface is implemented by
both the concrete DAO implementations, i.e. the NewsDAOOracleImpl and
NewsDAOOracleXMLDBImpl.
The NewsDAOOracleImpl and NewsDAOOracleXMLDBImpl
classes implements the NewsDAO interface.
The news application uses a business logic bean
named NewsBean. This bean contains all the business logic related
to the application. This bean is very light weight as there is not much of business
logic processing required before retrieving the data from the data-stores.
Thus it contains only the methods to retrieve data from the data-stores.
Software Requirements
The following softwares are required for configuring and running
this sample application
The directory where OC4J is installed. For e.g., D:\oc4j
<J2EE_HOME>
The directory j2ee/home under <OC4J_HOME>.
For e.g., D:\oc4j\j2ee\home
<JAVA_HOME>
Directory where JAVA is installed
<ANT_HOME>
Directory where Apache Ant is
installed
<ORACLE_HOME>
The directory where Oracle Database
is installed
<SAMPLE_HOME>
The directory where this sample
application is extracted. For e.g., D:\DAODesignPattern
Configuring the
Application
Unzip the provided DAODesignPattern.zip.
This creates DAODesignPattern directory with all the source files.
To create the database objects required for
the application, execute the creation.sql file under SCOTT
schema. You can do this by executing the following command in SQL*Plus :
sqlplus> @<SAMPLE_HOME>\creation.sql
To setup the database connection, edit the data-sources.xml
file in the <SAMPLE_HOME>\src\META-INF directory and
edit the following connection information within the <data-source>...</data-source>
tags.
Replace <hostName>:<port>:<database_SID>
in the url, with your database values and save the file. If required, replace
the username and password attributes.
where,
hostName
=
hostname of the machine
where Oracle database is running
port
=
port on the host machine
on which the database listener is listening
database_SID
=
SID of the database
Edit the file DAOImplementation.properties located in the <SAMPLE_HOME>\src
directory. The final two lines in this file specifies the data-store to be
used. If the value NewsDAOOracleImpl is selected for the property DAOImplementationClass,
then the application fetches the News information from the relational table.
If the selected value is NewsDAOOracleXMLDBImpl, then the information
is fetched from the XMLDB table. Change this value as required.
Deploying and Running
the Application
The application can be deployed and run in either of the following
ways:
This section describes the steps required
in deploying and running this application inside embedded OC4J using Oracle
JDeveloper 10g.
Open Oracle JDeveloper 10g and use File/Open
option to select the DAOWS.jws from the DAODesignPattern
directory
Next, select Project/Make DAOPrj.jpr
from main menu
Now, select Run/Run DAOPrj.jpr
from main menu which opens up the browser and runs the the
News application
Run the Application
using standalone OC4J
This section describes the steps
required in deploying this application to the Standalone OC4J using ANT Tool
and running using the browser.
Note:
Make sure that the environment variables [<JAVA_HOME>, <ANT_HOME>/bin
in the PATH; <JAVA_HOME>/bin in the PATH] have been set before proceeding
further. For more information on how to setup these environment variables,
please refer environment set up
readme document.
Ensure that OC4J is up and running. To start the OC4J
server, navigate to <OC4J_HOME>/j2ee/home and execute
the following command,
> java -jar oc4j.jar
Open the DAODesignPattern/config/server.properties
in a text editor. Change the following parameters to with your OC4J details.
OC4J_HOME
=
Directory where OC4J is installed. Ex: e:/oc4j10g
OC4J_HOST
=
Machine name or IP address on which OC4J is running
OC4J_PORT
=
ORMI port on which your OC4J listens for ORMI
requests
OC4J_USERNAME
=
User name of OC4J server, default is admin.
OC4J_PASSWORD
=
Password of OC4J server.
Build and deploy the EAR file using ANT. From DAODesignPattern
directory, execute the command
> ant
Open your favorite browser and access the sample application,
using the following URL,
http://<hostName>:<port>/dao/News.jsp
where,
<hostName> is the machine on which OC4J is running and <port>
is Port in which the OC4J server listens to HTTP requests. By default OC4J
listens for HTTP requests in port # 8888
Example: http://localhost:8888/dao/News.jsp
Sample Application
Files
This section will provide a tabular listing of the sample
application files, along with their respective directory locations and a description
of what they do in the overall scheme of the application.