Articles

Google's way of wishing you a Happy New Year

2010-01-04T14:40:00.007+05:30

Google has its own way to wish you a Happy New Year

Here is how to do it:

1. Go to Google.com or your country specific Google Home page

2. Do not type in the search box.

3. Hit I'm Feeling Lucky button.

4. Get Surprised

Seach videos for specific text with Gaudi - Googles new audio Indexing Service

2009-12-08T16:51:00.003+05:30

If you need to to find a video which has certain specific word, line or lyrics but you do not remember the name or title of the video or album, then try Gaudi.

Gaudi is a new Google labs feature which allows you to search for specific a text or audio in a video.

It has indexed the text or audio from videos available online much the same way as Google Images work.It uses speech technology to find spoken words inside videos and lets the user jump to the right portion of the video where these words are spoken.

How does it work
Google Audio Indexing uses speech technology to transform spoken words into text and leverages the Google indexing technology to return the best results to the user.
The returned videos are ranked based -- among other things -- on the spoken content, the metadata, the freshness.

Google periodically crawl the YouTube political channels for new content. As soon as a new video is uploaded to YouTube, it is processed by our system and made available in our index for people to search.

Popular video sites like YouTube and Google Video are supported.

Try Gaudi and let me know your experience in comments below.

JNI (Java Native Interface) - Generating a DLL using Turbo C/C++ Compiler

2009-11-04T18:25:00.025+05:30

This tutorial shows you how to write a JNI (Java Native Interface) program using Turbo C++ Compiler and JDK1.5 on a Windows XP machine.

Why Turbo C++ Compiler

Although Turbo C compiler is very old and there are many good C/C++ compiler available, like "Microsoft Visual C++" and other free compilers

This tutorial is basically to show that it’s possible to generate a windows System library (DLL) using Turbo C++ and which can be called by the JNI programs using it.

Borland Turbo C++ is the first C compiler I used to compile C programs but was always curious to know if JNI programming is possible with this compiler.

So here is a step-by-step process to write a small “Hello World” application using Turbo C and JDK1.5

Step-1: Download Turbo C and JDK.

This tutorial uses Turbo C++ 5.5 and JDK 1.5

Download links

Borland C++ Compiler 5.5

Sun JDK 1.5

Step-2: Install & Configure Turbo C

(a) Run the setup program. Just click the file (freecommandLinetools.exe)

By default, it installs to C:\Borland\BCC55 (This tutorial assumes this location).

(b) Add the /bin directory to the system PATH

In WinXP machine – you will add it under the “user variables” tab with name as “PATH”

(c)Create a configuration file for the bcc32 program that tells it where to find its libraries and include files.

Open a terminal or command prompt and type the following commands:

echo -I"C:\Borland\BCC55\Include" >> C:\Borland\BCC55\Bin\bcc32.cfg

echo -L"C:\Borland\BCC55\Lib" >> C:\Borland\BCC55\Bin\bcc32.cfg

echo -L"C:\Borland\BCC55\Lib" >> C:\Borland\BCC55\Bin\ilink32.cfg (Optional)

Step-3: Create Java class

Create a class (HelloWorld.java) that declares the native method

class HelloWorld {

static {
System.loadLibrary("HelloWorld");
}

private native void print();

public static void main(String[] args) {
new HelloWorld().print();
}
}

Compile the HelloWorld source file

javac HelloWorld.java

Step-4: Generate C Header file

Use javah.exe (included in JDK bin) to generate a C header file (HelloWorld.h) containing the function prototype for the native method implementation.


javah -jni HelloWorld

This will generates a file named HelloWorld.h.

Step-5: Writing the C implementation

The JNI header file generated by javah helps you to write C/C++ implementations for the native method. The function that you write must follow the prototype specified in the generated header file. The implementation (HelloWorld.c) looks as follows:

#include <jni.h>
#include <stdio.h>
#include "HelloWorld.h"

JNIEXPORT void JNICALL
Java_HelloWorld_print(JNIEnv *env, jobject obj)
{
printf("Hello World! using JNI \n");
return;
}

Step-6: Include JNI specific header

The C program just created will need the jni.h and other header files located in the

C:\jdk1.5.0_13\include and its subfolders.

For some reason I was not able to configure the bcc32.cfg, created earlier to read the location of these JNI specific header files from their original location.

So I have copied all the header files to C:\Borland\BCC55\Include

Step-7: Compile the C implementation into a native library

Its also perfectly ok to generate a .so file but or this example I use dll

Open a cmd and hit

bcc32 -WD HelloWorld.c

The above command will compile the HelloWorld.c generating some intermediary files along with HelloWorld.dll which is what we are interested in

The –WD option tells the compiler to generate a Windows specific DLL.

Step-8: Running the HelloWorld program

Running the HelloWorld program

Because the HelloWorld class contains a main method, you can now run the program on WinXP as follows:

java HelloWorld

You should see the following output.

output:

 
Hello World! Using JNI

 
You are done!


Conclusion:

The above tutorial shows a very
basic example of JNI using Turbo
C and JDK. I have not written
complex native programs using
this compiler (like performing
arithmetics or other System
programming), So I am not sure
of the scope of JNI you can write
using this compiler.

Turbo C++ is old and JNI include files might not support all the
language specific features.

Do let me know if this tutorial
was useful.

Write remarks/feedback or any issues in the comments section below.

Mac OS X Snow Leopard Causes Serious Troubles

2009-10-26T10:55:00.002+05:30

If you also have recently upgraded to the latest operating system from Apple the Mac OS X Snow Leopard, there is a high possibility that you wake up one day and find that your user account has been wiped clean. This bug in Mac OS X Snow Leopard causes the computer to wipe the user account, including data, personal files and documents. Users from around the world have reported this bug on the Apple forums.

The bug strikes when a user upgrades her system from Mac OS X Leopard to Snow Leopard, logs in to the guest account and then logs back in to the user account. The user account is restored back to default and all the files and personal data are deleted the moment user logs into the account.

Apple has been quiet on this issue and no solution has been posted on the forums. The only thing that is seen on the Apple forum is the growing list of victims of this new bug.

As of now those of you who have not expected any such problem, you should try to disable access to the guest account. So try not to access it until Apple patches this bug or finds a solution.

via [ConsumerMate]

The invention that will change the Internet world

2009-05-25T13:45:00.005+05:30

At the height of Mount Everest if you ask for extra Information like its physical condition, graphs, charts, location etc. getting it is not a surprise. So far, we have Google, Yahoo search engines which are prevalent.

America's Dr Stephen Volfram has launched a software 'Volfram alpha' which can do something better than a search engine could do. This software was recently presented at Harvard University. It is an information store of a global scale.

How it works:

This software will understand the problem in terms of simple inputs and suggest various solutions for that. Despite being a new system it has created excitement among Internet watchers and technologist. This software could prove to be better than Google, as it is capable of addressing many aspects and is impressive.

In this season, weather, heights etc can be compared depending on different countries.

To overcome weakness of sites like Wikipedia, it is based on Standard mathematical software that engineers and scientists use. This will keep itself updated with the latest discoveries and information from search engine database Cross checking with the contemporary collection of search, news can be done while solving a problem.

Read more at: Wolfram Blog

Try it here: Wolfram|Alpha

First look at MS Office 2010

2009-04-29T14:37:00.000+05:30

Office 2010, the next version of Microsoft's successful office programs suite, has been in closed testing for a while now. With a public beta expected later in the year, development is stepping up before the program, previously dubbed Office 14, is finally let out into the wild.

Here are some images of the new about screen of Office and screenshots of the new version of Outlook, including the ribbon toolbar. Click the images to enlarge where they are scaled down.

INDIA - Fixtures 2007-2008

2007-10-01T11:29:00.000+05:30

Australia in India , 2007 Fixtures
September 2007
Date	Match Details	Venue
Sat 29	India v Australia , 1st ODI	Bangalore
October 2007
Date	Match Details	Venue
Tue 02	India v Australia , 2nd ODI	Kochi
Fri 05	India v Australia , 3rd ODI	Hyderabad
Mon 08	India v Australia , 4th ODI	Guwahati
Thu 11	India v Australia , 5th ODI	Baroda
Sun 14	India v Australia , 6th ODI	Nagpur
Wed 17	India v Australia , 7th ODI	Mumbai

Pakistan in India , 2007 Fixtures
November 2007
Date	Match Details	Venue
Tue 06	India v Pakistan , 1st ODI	Faridabad
Fri 09	India v Pakistan , 2nd ODI	Mohali
Mon 12	India v Pakistan , 3rd ODI	Kanpur
Thu 15	India v Pakistan , 4th ODI	Gwalior
Sun 18	India v Pakistan , 5th ODI	Jaipur
Thu 22 - Mon 26	India v Pakistan , 1st Test	Delhi
Fri 30 - Tue 04	India v Pakistan , 2nd Test	Kolkata
Sat 08 - Wed 12	India v Pakistan , 3rd Test	Bangalore

India in Australia , 2007/08 Fixtures
December 2007
Date	Match Details	Venue
Wed 26 - Sun 30	Australia v India , 1st Test	Melbourne
January 2008
Date	Match Details	Venue
Wed 02 - Sun 06	Australia v India , 2nd Test	Sydney
Wed 16 - Sun 20	Australia v India , 3rd Test	Perth
Thu 24 - Mon 28	Australia v India , 4th Test	Adelaide
February 2008
Date	Match Details	Venue
Fri 01	Australia v India , Only T20I	Melbourne

CommonWealth Bank Series 2008 Fixtures
February 2008
Date	Match Details	Venue
Sun 03	Australia v India, 1st Game, CommonWealth Bank Series 2008	Brisbane
Tue 05	India v Sri Lanka, 2nd Game, CommonWealth Bank Series 2008	Brisbane
Fri 08	Australia v Sri Lanka , 3rd Game, CommonWealth Bank Series 2008	Sydney
Sun 10	Australia v India, 4th Game, CommonWealth Bank Series 2008	Melbourne
Tue 12	India v Sri Lanka, 5th Game, CommonWealth Bank Series 2008	Canberra
Fri 15	Australia v Sri Lanka , 6th Game, CommonWealth Bank Series 2008	Perth
Sun 17	Australia v India, 7th Game, CommonWealth Bank Series 2008	Adelaide
Tue 19	India v Sri Lanka, 8th Game, CommonWealth Bank Series 2008	Adelaide
Fri 22	Australia v Sri Lanka , 9th Game, CommonWealth Bank Series 2008	Melbourne
Sun 24	Australia v India, 10th Game, CommonWealth Bank Series 2008	Sydney
Tue 26	India v Sri Lanka, 11th Game, CommonWealth Bank Series 2008	Hobart
Fri 29	Australia v Sri Lanka , 12th Game, CommonWealth Bank Series 2008	Melbourne
March 2008
Date	Match Details	Venue
Sun 02	1st Final, CommonWealth Bank Series 2008	Sydney
Tue 04	2nd Final, CommonWealth Bank Series 2008	Brisbane
Fri 07	3rd Final, CommonWealth Bank Series 2008	Adelaide

The Basics of Oracle Architecture

2007-09-20T11:19:00.000+05:30

Basically, there are two main components of Oracle database –– instance and database itself. An instance consists of some memory structures and the background processes, whereas a database refers to the disk resources. Figure 1 will show you the relationship.

Figure 1. Two main components of Oracle database

Instance

As we cover above, the memory structures and background processes contitute an instance. The memory structure itself consists of System Global Area (SGA), Program Global Area (PGA), and an optional area –– Software Area Code. In the other hand, the mandatory background processes are Database Writer (DBWn), Log Writer (LGWR), Checkpoint (CKPT), System Monitor (SMON), and Process Monitor (PMON). And another optional background processes are Archiver (ARCn), Recoverer (RECO), etc. Figure 2 will illustrate the relationship for those components on an instance.

What is An Oracle Database?

Figure 2. The instance components

System Global Area

SGA is the primary memory structures. When Oracle DBAs talk about memory, they usually mean the SGA. This area is broken into a few of part memory –– Buffer Cache, Shared Pool, Redo Log Buffer, Large Pool, and Java Pool.

Buffer Cache

Buffer cache is used to stores the copies of data block that retrieved from datafiles. That is, when user retrieves data from database, the data will be stored in buffer cache. Its size can be manipulated via DB_CACHE_SIZE parameter in init.ora initialization parameter file.

Shared Pool

Shared pool is broken into two small part memories –– Library Cache and Dictionary Cache. The library cache is used to stores information about the commonly used SQL and PL/SQL statements; and is managed by a Least Recently Used (LRU) algorithm. It is also enables the sharing those statemens among users. In the other hand, dictionary cache is used to stores information about object definitions in the database, such as columns, tables, indexes, users, privileges, etc.

The shared pool size can be set via SHARED_POOL_SIZE parameter in init.ora initialization parameter file.

Redo Log Buffer

Each DML statement (insert, update, and delete) executed by users will generates the redo entry. What is a redo entry? It is an information about all data changes made by users. That redo entry is stored in redo log buffer before it is written into the redo log files. To manipulate the size of redo log buffer, you can use the LOG_BUFFER parameter in init.ora initialization parameter file.

Large Pool

Large pool is an optional area of memory in the SGA. It is used to relieves the burden place on the shared pool. It is also used for I/O processes. The large pool size can be set by LARGE_POOL_SIZE parameter in init.ora initialization parameter file.

Java Pool

As its name, Java pool is used to services parsing of the Java commands. Its size can be set by JAVA_POOL_SIZE parameter in init.ora initialization parameter file.

Program Global Area

Although the result of SQL statemen parsing is stored in library cache, but the value of binding variable will be stored in PGA. Why? Because it must be private or not be shared among users. The PGA is also used for sort area.

Software Area Code

Software area code is a location in memory where the Oracle application software resides.

Oracle Background Processes

Oracle background processes is the processes behind the scene that work together with the memories.

DBWn

Database writer (DBWn) process is used to write data from buffer cache into the datafiles. Historically, the database writer is named DBWR. But since some of Oracle version allows us to have more than one database writer, the name is changed to DBWn, where n value is a number 0 to 9.

LGWR

Log writer (LGWR) process is similar to DBWn. It writes the redo entries from redo log buffer into the redo log files.

CKPT

Checkpoint (CKPT) is a process to give a signal to DBWn to writes data in the buffer cache into datafiles. It will also updates datafiles and control files header when log file switch occurs.

SMON

System Monitor (SMON) process is used to recover the system crach or instance failure by applying the entries in the redo log files to the datafiles.

PMON

Process Monitor (PMON) process is used to clean up work after failed processes by rolling back the transactions and releasing other resources.

Database

The database refers to disk resources, and is broken into two main structures –– Logical structures and Physical structures.

Logical Structures

Oracle database is divided into smaller logical units to manage, store, and retrieve data effeciently. The logical units are tablespace, segment, extent, and data block. Figure 3 will illustrate the relationships between those units.

Figure 3. The relationships between the Oracle logical structures

Tablespace

A Tablespace is a grouping logical database objects. A database must have one or more tablespaces. In the Figure 3, we have three tablespaces –– SYSTEM tablespace, Tablespace 1, and Tablespace 2. Tablespace is composed by one or more datafiles.

Segment

A Tablespace is further broken into segments. A segment is used to stores same type of objects. That is, every table in the database will store into a specific segment (named Data Segment) and every index in the database will also store in its own segment (named Index Segment). The other segment types are Temporary Segment and Rollback Segment.

Extent

A segment is further broken into extents. An extent consists of one or more data block. When the database object is enlarged, an extent will be allocated. Unlike a tablespace or a segment, an extent cannot be named.

Data Block

A data block is the smallest unit of storage in the Oracle database. The data block size is a specific number of bytes within tablespace and it has the same number of bytes.

Physical Structures

The physical structures are structures of an Oracle database (in this case the disk files) that are not directly manipulated by users. The physical structure consists of datafiles, redo log files, and control files.

Datafiles

A datafile is a file that correspondens with a tablespace. One datafile can be used by one tablespace, but one tablespace can has more than one datafiles.

Redo Log Files

Redo log files are the files that store the redo entries generated by DML statements. It can be used for recovery processes.

Control Files

Control files are used to store information about physical structure of database, such as datafiles size and location, redo log files location, etc.

Abstract Factory Pattern

2007-07-18T18:01:00.000+05:30

The essence of a pattern is a reusable solution for a recurring problem. A complete pattern will also provide reasons to use or not use the solution, the consequences of using the solution, and suggestions on how to implement the solution. The summaries in these articles will just describe the essential problem and its solution.
Abstract Factory

Suppose you have the task of building a user interface framework that works on top of multiple windowing systems, like MS-Windows, Motif, or Mac OS. It must work on each platform with the platform's native look and feel. You organize it by creating an abstract class for each type of widget (text field, push button, list box, etc.) and then writing a concrete subclass of each of those classes for each supported platform. To make this robust, you need to ensure that the widget objects created are all for the desired platform. That is where the abstract factory comes into play.

An abstract factory class defines methods to create an instance of each abstract class that represents a user interface widget. Concrete factories are concrete subclasses of an abstract factory that implements its methods to create instances of concrete widget classes for the same platform.

In a more general context, an abstract factory class and its concrete subclasses organize sets of concrete classes that work with different but related products. For a broader perspective, consider another situation.

Suppose you are writing a program that performs remote diagnostics on computers made by a computer manufacturer called Stellar Microsystems. Over time, Stellar has produced computer models having substantially different architectures. Their oldest computers used CPU chips from Enginola that had a traditional complex instruction set. Since then, they have released three generations of computers based on their own reduced instruction set architectures called ember, super-ember, and ultra-ember. The core components used in these models perform similar functions but involve different sets of components.

For the program you are writing to know which tests to run and how to interpret the results, it will need to instantiate objects that correspond to each one of the core components in the computer being diagnosed. The class of each object will correspond to the type of component to be tested. That means you will have a set of classes for each computer architecture. There will be a class in each set corresponding to the same type of computer component. Because this situation fits the Abstract Factory pattern so well, you can use that pattern to organize the creation of objects that correspond to core computer components.

Here is a class diagram showing classes for only two types of components in only two architectures:

Figure 1. Abstract Factory example.

An instance of the Client class manages the remote diagnostic process. When it determines the architecture of the machine it has to diagnose, it calls the ArchitectureToolkit class's getFactory method. That static method returns an instance of a class such as EmberToolkit or EnginolaToolkit that corresponds to the architecture that the Client object passed to the getFactory method. The Client object can then use that toolkit object to create objects that model CPUs, MMUs, and other components of the required architecture.

Now we will consider the more general case. The following class diagram shows the roles that classes play in the Abstract Factory pattern.

Here is a class diagram that shows the roles that classes and interfaces play in the Abstract Factory pattern.

Figure 2. Abstract Factory, classes and interfaces example.

Client
Classes in the Client role use various widget classes to request or receive services from the product that the client is working with. Client classes only know about the abstract widget classes. They should have no knowledge of any concrete widget classes.
AbstractFactory
AbstractFactory classes define abstract methods for creating instances of concrete widget classes.
Abstract factory classes have a static method shown in the above diagram as getFactory. Another common name for that method is getToolkit. A Client object calls that method to get an instance of a concrete factory appropriate for working with a particular product.
ConcreteFactory1, ConcreteFactory2
Classes in this role implement the methods defined by their abstract factory superclasses to create instances of concrete widget classes. Client classes that call these methods should not have any direct knowledge of these concrete factory classes, but instead access singleton instances of these classes by calling a method of their abstract factory superclass.
WidgetA, WidgetB
Interfaces in this role correspond to a feature of a product. Classes that implement an interface in this role work with the product to which the interface corresponds.
Product1WidgetA, Product2WidgetA. . .
Classes in this role are concrete classes that correspond to a feature of a product that they work with. You can generically refer to classes in this role as concrete widgets.

An implementation issue for the Abstract Factory pattern is the mechanism the abstract factory class's getFactory method uses to select the class of the concrete factory it returns to client objects. The simplest situation is when client objects only need to work with one product during the run of a program. In that case, the abstract factory class will typically have a static variable set to the concrete factory class that is used for the duration of the program run. The abstract factory class's getFactory method can then just return an instance of that class.

If the abstract factory object will use information provided by the requesting client to select among multiple concrete factory objects, you can hard code the selection logic and choice of concrete factory objects in the abstract factory class. That strategy has the advantage of simplicity. It has the drawback of requiring a source code modification to add a new concrete factory class.

A different strategy is to use a Hashed Adapter pattern. It separates the selection logic for concrete factories from the data it uses to make the selection. It works by putting references to concrete factory classes, along with the information used to select them, into a data structure, which is typically a HashMap or a Hashtable. The data structure allows an abstract factory to select a concrete factory object by performing a lookup on the data structure. The advantage of using the data structure is that it is possible to devise schemes for building the data structure that allow an abstract factory to work with new concrete factory classes at runtime without any source code modification.

Here is some of the Java code that implements the design for remote computer diagnostics presented earlier in this article. The widget interfaces have the obvious structure:

public abstract class CPU {
...
} // class CPU

The concrete widget classes are simply classes that implement the widget interfaces:

class EmberCPU extends CPU {
...
} // class EmberCPU

Below is code for a concrete factory class that creates instances of classes to test ember architecture computers:

class EmberToolkit extends ArchitectureToolkit {
public CPU createCPU() {
return new EmberCPU();
} // createCPU()

public MMU createMMU() {
return new EmberMMU();
} // createMMU()
...
} // class EmberFactory

Below is the code for the abstract factory class:

public abstract class ArchitectureToolkit {
private static final EmberToolkit emberToolkit = new
EmberToolkit();
private static final EnginolaToolkit
enginolaToolkit
= new EnginolaToolkit();
...

/**
* Returns a concrete factory object that is an
instance of the
* concrete factory class appropriate for the given
architecture.
*/
static final ArchitectureToolkit getFactory(int
architecture) {
switch (architecture) {
case ENGINOLA:
&nbs
p; return enginolaToolkit;

case EMBER:
&nbs
p; return emberToolkit;
...
} // switch
String errMsg =
Integer.toString(architecture);
throw new
IllegalArgumentException(errMsg);
} // getFactory()

public abstract CPU createCPU() ;
public abstract MMU createMMU() ;
...
} // AbstractFactory

Client classes typically create concrete widget objects using code that looks something like this:
public class Client {
public void doIt () {
AbstractFactory af;
af =
AbstractFactory.getFactory(AbstractFactory.EMBER);
CPU cpu = af.createCPU();
...
} // doIt
} // class Client

Development with JSP and XML-- Part II: JSP with XML in mind

2007-07-13T11:33:00.000+05:30

Development with JSP and XML-- Part II: JSP with XML in mind

A Primer on Spring's Data Access Object (DAO) Framework

2007-07-10T18:20:00.000+05:30

07/10/2007

Abstract

The business components in J2EE applications typically use the JDBC API to access and change persistent data in relational databases. This often leads to the mixing of persistence code with business logic—a bad idea. The Data Access Object (DAO) design pattern addresses this problem by separating the persistence logic into data access classes.

This article is a primer on DAO design pattern, highlighting its merits and demerits. It then introduces the Spring 2.0 JDBC/DAO framework and demonstrates how it elegantly addresses the drawbacks in traditional DAO design.

Traditional DAO Design

Data Access Object (DAO) is an integration tier design pattern as cataloged in the book Core J2EE Design Pattern. It encapsulates persistence store access and manipulation code into a separate layer. The persistent store in the context of this article is an RDBMS.

This pattern introduces an abstraction layer between the business logic tier and the persistent storage tier, as shown in Figure 1. Business objects access the RDBMS (data source) through the data access objects. This abstraction layer streamlines application code and introduces flexibility. Ideally, changes made to the data source, such as switching database vendors or type, would require changes only to the data access objects and should have minimal impact on the business objects.

Figure 1. Application structure, before and after DAO

Now that I've explained the basics of the DAO design pattern, it's time to write some code. The examples below are from a company domain model. To put it simply, the company has several employees working in various departments such as sales, marketing, and HR. For the sake of simplicity, I will concentrate on a single entity called "Employee."

Program to an interface

The flexibility the DAO design pattern provides is attributed primarily to a best practice for object design: Program to an Interface (P2I). This principle states that concrete objects must implement an interface that is used in the caller program rather than the concrete object itself. Therefore, you can easily substitute a different implementation with little impact on client code.

Going by this mantra I will define the Employee DAO interface, IEmployeeDAO, with a behavior findBySalaryRange(). The business components will interact with the DAOs through this interface:

import java.util.Map;
public interface IEmployeeDAO {
//SQL String that will be executed
public String FIND_BY_SAL_RNG = "SELECT EMP_NO, EMP_NAME, "
+ "SALARY FROM EMP WHERE SALARY >= ? AND SALARY <= ?";   //Returns the list of employees who fall into the given salary  //range. The input parameter is the immutable map object  //obtained from the HttpServletRequest. This is an early  //refactoring based on "Introduce Parameter Object"   public List findBySalaryRange(Map salaryMap); }

Providing the DAO implementation classes

Having defined the interface, now I must provide a concrete implementation of the Employee DAO, EmployeeDAOImpl:

import java.sql.Connection;
import java.sql.PreparedStatement;
import java.sql.ResultSet;
import java.util.List;
import java.util.ArrayList;
import java.util.Map;
import com.bea.dev2dev.to.EmployeeTO;

public class EmployeeDAOImpl implements IEmployeeDAO{

public List findBySalaryRange(Map salaryMap)
{
 Connection conn = null;
 PreparedStatement pstmt = null;
 ResultSet rs = null;
 List empList = new ArrayList();
 //Transfer Object for inter-tier data transfer
 EmployeeTO tempEmpTO = null;
 try{
 //DBUtil - helper classes that retrieve connection from pool
   conn = DBUtil.getConnection();
   pstmt = conn.prepareStatement(FIND_BY_SAL_RNG);
   pstmt.setDouble(1, Double.valueOf( (String)
       salaryMap.get("MIN_SALARY") );
   pstmt.setDouble(2, Double.valueOf( (String)
       salaryMap.get("MIN_SALARY") );
   rs = pstmt.executeQuery();
   int tmpEmpNo = 0;
   String tmpEmpName = "";
   double tmpSalary = 0.0D;
   while (rs.next()){
     tmpEmpNo = rs.getInt("EMP_NO");
     tmpEmpName = rs.getString("EMP_NAME");
     tmpSalary = rs.getDouble("SALARY");
     tempEmpTO = new EmployeeTO(tmpEmpNo,
           tmpEmpName,
           tmpSalary);
     empList.add(tempEmpTO);
   }//end while
 }//end try
 catch (SQLException sqle){
   throw new DBException(sqle);
 }//end catch
 finally{
   try{
     if (rs != null){
       rs.close();
     }
   }
   catch (SQLException sqle){
     throw new DBException(sqle);
   }
   try{
     if (pstmt != null){
       pstmt.close();
     }     
   }
   catch (SQLException sqle){
     throw new DBException(sqle);
   }
   try{
     if (conn != null){
       conn.close();
     }     
   }
   catch (SQLException sqle){
     throw new DBException(sqle);
   }
 }//end of finally block
 return empList;
}//end method findBySalaryRange
}

The above listing illustrates these key points about DAO methods:

They encapsulate all interactions with the JDBC API. If an O/R mapping solution like Kodo or Hibernate were being used, the DAO classes can wrap the proprietary APIs of these products.
They wrap the retrieved data in a JDBC API-neutral transfer object and returns it to the business tier for further processing.
They are stateless in nature. Their sole aim is to access and change persistent data for the business objects.
They trap any errors (for example, database is unavailable, wrong SQL syntax) reported in the process by the underlying JDBC API or database as SQLException. The DAO objects notify the business objects of such errors again by a JDBC-neutral, custom build runtime exception class DBException.
They release database resources like Connection and PreparedStatement objects back to the pool and relinquish memory held by ResultSet cursors after they have been used.

Therefore, the DAO layer provides a consistent data access API for the business tier abstracting the low level data access API.

Building the DAO Factory

The DAO Factory is a typical factory design pattern implementation for creating and serving concrete DAO implementations to the business objects. The business objects use the DAO interfaces and are not aware of the implementation classes. This dependency inversion due to the DAO factory provides enormous flexibility. It is easy to alter DAO implementation (for example, from straight JDBC to Kodo-based O/R mapping) without affecting the client business objects, as long as the contract established by the DAO interfaces remains unchanged:

public class DAOFactory {
private static DAOFactory daoFac;

static{
 daoFac = new DAOFactory();
}

private DAOFactory(){}

public DAOFactory getInstance(){
 return daoFac;
}

public IEmployeeDAO getEmployeeDAO(){
 return new EmployeeDAOImpl();
}
}

Collaborating with the business components

Now it's time to see how DAOs fit into the bigger picture. As mentioned in previous sections, the DAOs collaborate with the business tier components to fetch and change persistent business data. This listing shows the business service component and its interaction with the DAO tier:

public class EmployeeBusinessServiceImpl implements
                                    IEmployeeBusinessService {

public List getEmployeesWithinSalaryRange(Map salaryMap){

 IEmployeeDAO empDAO = DAOFactory.getInstance()
                                 .getEmployeeDAO();
 List empList = empDAO.findBySalaryRange(salaryMap);
 return empList;
}
}

This is nice and clean, with no reliance on any persistence interfaces (including JDBC) at all.

Problems

The DAO design pattern is not devoid of shortcomings:

Code Repetition: As evident from the EmployeeDAOImpl listing, code repetition (shown in bold above) is a major problem with JDBC-based, traditional database access. Writing boilerplate code over and over is a clear violation of the basic OO principle of code reuse. This has obvious side effects in terms of project cost, timelines, and effort.
Coupling: The DAO code is very tightly coupled with the JDBC interfaces and core collections. This is evident from the number of import statements per DAO class.
Resource Leakage: Following the design of the EmployeeDAOImpl class, all DAO methods must relinquish control of acquired database resources like connection, statements, and result sets. This is a risky proposition because a novice programmer can very easily skip those bits. As a result, resources would run out and bring the system to a halt.
Error Handling: JDBC drivers report all error situations by raising the SQLException. SQLException is a checked exception, therefore developers are forced to handle it—even though it isn't possible to recover from the majority of these exceptions, which results in cluttering the code. Moreover, the error code and message obtained from the SQLException object are database vendor-specific, so it's not possible to write portable DAO error messaging code.
Fragile Code: The setting of the bind variables for the statement object, and the retrieval of the data using the result set getter methods are two frequently used tasks in JDBC-based DAO. If the number of columns in the SQL where clause is changed, or the column positions are altered, the code has to go through the rigorous cycle of change, test, and redeployment.

Let's look at how to maintain the majority of the benefits of DAO while doing away with these problems.

Enter Spring DAO

The problems listed above can be solved by identifying the portions of the code that vary, and then separating or encapsulating them from the code that remains fixed. The designers of Spring have done exactly that and have come out with an ultra-thin, robust, and highly extensible JDBC framework. The fixed parts (like retrieving connection, preparing the statement object, executing the query, and releasing the database resources) have been written once and correctly—so part of this framework helps to eliminate the shortcomings found in traditional JDBC-based DAO.

Figure 2 shows the major building blocks of the Spring JDBC framework. The business service objects continue to use the DAO implementation classes through appropriate interfaces. JdbcDaoSupport is the super class for JDBC data access objects. It is associated with a particular datasource. The Spring Inversion of Control (IOC) container, or the BeanFactory, is responsible for getting the appropriate datasource configuration details and associating them with JdbcDaoSupport. The most important functionality of this class is to make the JdbcTemplate object available to the subclasses.

Figure 2. Major components of the Spring JDBC framework

JdbcTemplate is the most important class in the Spring JDBC framework. To quote the documentation, "it simplifies the use of JDBC and helps to avoid common errors. It executes core JDBC workflow, leaving application code to provide SQL and extract results." This class helps separate the static parts of JDBC DAO code by performing these boilerplate tasks:

Retrieves connections from the datasource.
Prepares appropriate statement object.
Executes SQL CRUD operations.
Iterates over result sets and populates the results in standard collection objects.
Handles SQLException exceptions and translates them to a more error-specific exception hierarchy.

Rewriting Using Spring DAO

Now that you have a basic understanding of the Spring JDBC framework, it is time to rewrite the existing code. I will take a step-by-step approach and, in the process, discuss how to overcome the problems stated in the previous section.

Step 1: Alter DAO Implementation class - The EmployeeDAOImpl now extends from JdbcDaoSupport to get hold of JdbcTemplate.

import org.springframework.jdbc.core.support.JdbcDaoSupport;
import org.springframework.jdbc.core.JdbcTemplate;

public class EmployeeDAOImpl extends JdbcDaoSupport
                                  implements IEmployeeDAO{

public List findBySalaryRange(Map salaryMap){

 Double dblParams [] = {Double.valueOf((String)
         salaryMap.get("MIN_SALARY"))
           ,Double.valueOf((String)
         salaryMap.get("MAX_SALARY"))
       };
 //The getJdbcTemplate method of JdbcDaoSupport returns an
 //instance of JdbcTemplate initialized with a datasource by the
 //Spring Bean Factory
 JdbcTemplate daoTmplt = this.getJdbcTemplate();
 return daoTmplt.queryForList(FIND_BY_SAL_RNG,dblParams);
}
}

In the listing above, the values from the incoming parameter map are stored in a double array, in the same order as the positional parameters in the SQL string. The query results are returned by the queryForList() method as a List (one entry for each row) of Maps (one entry for each column, using the column name as the key). Later I'll show you how to return a list of transfer objects.

From the simplified code, it is evident that JdbcTemplate fosters reuse, and this has resulted in significant code reduction in the DAO implementation. The tight coupling with the JDBC and collection packages has been removed. Leakage of JDBC resource is no longer a problem as JdbcTemplate methods ensure that database resources are released in the proper sequence after they have been used.

In addition, you are not forced to handle exceptions while using Spring DAO. The JdbcTemplate class handles the SQLException , and translates it into a Spring-specific exception hierarchy based on SQL error codes or the error states. For example, DataIntegrityViolationException is raised when there is an attempt to insert duplicate values in a primary key column. However, you need not handle this exception if you cannot recover from this error. This is possible because the root exception class in Spring DAO, DataAccessException is a runtime exception. It is noteworthy that the Spring DAO exceptions are independent of the data access implementation. The same exceptions are raised if the implementation is provided by O/R mapping solutions.

Step 2: Alter Business Service - The business service now implements a new method setDao(), which is used by the Spring container to pass a reference of the DAO implementation class. This process is called "setter injection," and the Spring container is informed of this via the configuration file shown in Step 3. Note that it is no longer necessary to use the DAOFactory as the Spring BeanFactory compliments that functionality:

public class EmployeeBusinessServiceImpl
                      implements IEmployeeBusinessService {

IEmployeeDAO empDAO;

public List getEmployeesWithinSalaryRange(Map salaryMap){

 List empList = empDAO.findBySalaryRange(salaryMap);
 return empList;
}
public void setDao(IEmployeeDAO empDAO){
 this.empDAO = empDAO;
}
}

You see the flexibility of P2I; there is only a minimal change in the business service implementation, even though I have overhauled the DAO implementation. The minimal impact is due to the business services now being managed by the Spring container.

Step 3: Configure Bean Factory - The Spring bean factory needs a configuration file to initialize and start the Spring framework. This configuration file enlists all the business service and DAO implementation classes with the Spring bean container. Apart from this, it also has the information to initialize the datasource and JdbcDaoSupport:




"http://www.springframework.org/dtd/spring-beans.dtd">


  
  
    class="org.springframework.jndi.JndiObjectFactoryBean"> 
     
      
        
          weblogic.jndi.WLInitialContextFactory
        
        
          t3://localhost:7001
        
      
     
     
      
        jdbc/DBPool
       
    
  

  
  
    
      
    
  

  
  
  class="com.bea.dev2dev.sampleapp.business.EmployeeBusinessServiceImpl">

The Spring bean container sets the datasource object with the DAO implementation, by invoking the setDataSource() method available from JdbcDaoSupport. It also takes the responsibility of supplying the business service with the DAO implementation.

Step 4: Test - Finally it's time to write the JUnit test class. Going by Spring philosophy, I will test it outside the container. However, as evident from the configuration file in Step 3, I have been using the WebLogic Server connection pool.

package com.bea.dev2dev.business;

import java.util.*;
import junit.framework.*;
import org.springframework.context.ApplicationContext;
import org.springframework.context.support.FileSystemXmlApplicationContext;

public class EmployeeBusinessServiceImplTest extends TestCase {
  private IEmployeeBusinessService empBusiness;
  private Map salaryMap;
  List expResult;

  protected void setUp() throws Exception {
      initSpringFramework();
      initSalaryMap();
      initExpectedResult();
  }
  private void initExpectedResult() {
      expResult = new ArrayList();
      Map tempMap = new HashMap();
      tempMap.put("EMP_NO",new Integer(1));
      tempMap.put("EMP_NAME","John");
      tempMap.put("SALARY",new Double(46.11));
      expResult.add(tempMap);
  }
  private void initSalaryMap() {
      salaryMap = new HashMap();
      salaryMap.put("MIN_SALARY","1");
      salaryMap.put("MAX_SALARY","50");
  }
  private void initSpringFramework() {
    ApplicationContext ac = new FileSystemXmlApplicationContext
 ("C:/SpringConfig/Spring-Config.xml");
    empBusiness =
           (IEmployeeBusinessService)ac.getBean("EMP_BUSINESS");
  }
  protected void tearDown() throws Exception {
  }

  /**
   * Test of getEmployeesWithinSalaryRange method,
   * of class
   * com.bea.dev2dev.business.EmployeeBusinessServiceImpl.
   */
  public void testGetEmployeesWithinSalaryRange() {
    List result = empBusiness.getEmployeesWithinSalaryRange
    (salaryMap);
    assertEquals(expResult, result);      
  }   




}

Using Bind Variables

So far, I have been searching employees between a minimum and maximum salary range. Let's assume a hypothetical scenario where the business users want that range to be reversed. The DAO code is fragile and would have to change to cater to modified requirements. The problem lies with the use of positional bind variables (denoted by "?") that are static. Spring DAO comes to the rescue by providing support for named bind variables. The modified listing of IEmployeeDAO introduces named bind variables (denoted by ":"). Note the change in query, as shown below:

import java.util.Map; public interface IEmployeeDAO { //SQL String that will be executed public String FIND_BY_SAL_RNG = "SELECT EMP_NO, EMP_NAME, " + "SALARY FROM EMP WHERE SALARY >= :max AND SALARY <= :min"; //Returns the list of employees falling into the given salary range //The input parameter is the immutable map object obtained from //the HttpServletRequest. This is an early refactoring based on //- "Introduce Parameter Object" public List findBySalaryRange(Map salaryMap); }

The majority of JDBC drivers support only positional bind variables. Therefore, at runtime Spring DAO transforms this query to a positional bind, variable-based query and sets the appropriate bind variables. In order to perform these tasks, you now need to use the NamedParameterJdbcDaoSupport and NamedParameterJdbcTemplate classes, instead of JdbcDaoSupport and JdbcTemplate . Here is the modified DAO implementation class:

import org.springframework.jdbc.core.namedparam.NamedParameterJdbcDaoSupport; import org.springframework.jdbc.core.namedparam.NamedParameterJdbcTemplate; public class EmployeeDAOImpl extends NamedParameterJdbcDaoSupport implements IEmployeeDAO{ public List findBySalaryRange(Map salaryMap){ NamedParameterJdbcTemplate tmplt = this.getNamedParameterJdbcTemplate(); return tmplt.queryForList(IEmployeeDAO.FIND_BY_SAL_RNG ,salaryMap); } }

The getNamedParameterJdbcTemplate() method of NamedParameterJdbcDaoSupport returns an instance of NamedParameterJdbcTemplate, pre-initialized with the datasource handle. The Spring Beanfactory performs the initialization tasks, getting all the details from the configuration file. NamedParameterJdbcTemplate delegates the operation to JdbcTemplate once the substitution from the named parameters to positional placeholders is done at execution time. You can see that the use of named parameters makes the DAO methods immune to any kind of change in the underlying SQL statement.

Finally, the initSalaryMap() method in the JUnit test class needs a slight modification, as shown below, in case your database does not support automatic type conversion.

private void initSalaryMap() { salaryMap = new HashMap(); salaryMap.put("MIN_SALARY",new Double(1)); salaryMap.put("MAX_SALARY",new Double(50)); }

Spring DAO Callbacks

So far I've shown how the static parts of JDBC code have been encapsulated and generalized in the JdbcTemplate class to solve the problems in traditional DAO design. Now let's turn the focus to the variable aspects, like setting bind variables and iterating over ResultSets. Although Spring DAO has generalized solutions to these problems, in certain SQL-based conditions, you may need to set the bind variables.

In the endeavor to switch over to Spring DAO, I have introduced a subtle runtime error, due to a broken contract between the business service and its clients. The source of this error can be traced back to the original DAO. It no longer returns a list of EmployeeTO instances. Rather, the dbcTemplate.queryForList() method returns a list of maps (each map being a row in the result set).

As you know by now, the JdbcTemplate is based on the template method design pattern that defines the SQL execution workflow using the JDBC API. This workflow has to be altered to fix the broken contract. The first option is to alter/extend the workflow in a subclass. You can iterate over the list returned by JdbcTemplate.queryForList() and replace the map objects with EmployeeTO instances. However, this leads to the mingling of static and dynamic code, which I have been so desperately trying to avoid. The second option is to plug the code into various workflow alteration hooks provided by JdbcTemplate. It would be wise to encapsulate the transfer object population code in a different class, and then link it through the hook. Any alteration in the population logic will still leave the DAO unchanged.

The second option is achieved through classes that implement a method defined in a Spring framework-specific interface. These methods are called callbacks and are registered with the framework through JdbcTemplate. These methods are invoked by the framework when an appropriate event (for example, ResultSet has to be iterated and populated in framework-independent transfer objects) occurs.

Step 1: The transfer object

Here is the transfer object that you may be interested in. Note that the transfer object presented below is fixed:

package com.bea.dev2dev.to; public final class EmployeeTO implements Serializable{ private int empNo; private String empName; private double salary; /** Creates a new instance of EmployeeTO */ public EmployeeTO(int empNo,String empName,double salary) { this.empNo = empNo; this.empName = empName; this.salary = salary; } public String getEmpName() { return this.empName; } public int getEmpNo() { return this.empNo; } public double getSalary() { return this.salary; } public boolean equals(EmployeeTO empTO){ return empTO.empNo == this.empNo; } }

Step 2: Implement the callback interface

The RowMapper interface is implemented to populate the transfer objects from the result set. Here's an example:

package com.bea.dev2dev.dao.mapper; import com.bea.dev2dev.to.EmployeeTO; import java.sql.ResultSet; import java.sql.SQLException; import org.springframework.jdbc.core.RowMapper; public class EmployeeTOMapper implements RowMapper{ public Object mapRow(ResultSet rs, int rowNum) throws SQLException{ int empNo = rs.getInt(1); String empName = rs.getString(2); double salary = rs.getDouble(3); EmployeeTO empTo = new EmployeeTO(empNo,empName,salary); return empTo; } }

Note that the implementation class should not call the next() method on the supplied ResultSet object. This is taken care of by the framework, and it should extract only values from the current row of the result set. Any SQLException raised by the callback implementation is also handled by the Spring framework.

Step 3: Plug in the callback interface

JdbcTemplate uses a default RowMapper implementation to produce a list of maps when a SQL query is executed. I now need to register the custom callback implementation to alter this behavior of JdbcTemplate. Note that I am now using the query() method of NamedParameterJdbcTemplate, instead of the queryForList() method:

public class EmployeeDAOImpl extends NamedParameterJdbcDaoSupport implements IEmployeeDAO{ public List findBySalaryRange(Map salaryMap){ NamedParameterJdbcTemplate daoTmplt = getNamedParameterJdbcTemplate(); return daoTmplt.query(IEmployeeDAO.FIND_BY_SAL_RNG, salaryMap, new EmployeeTOMapper()); } }

The Spring DAO framework iterates through the results returned after the query execution. At each step of the iteration, it invokes the mapRow() method implemented by the EmployeeTOMapper class to populate each row of the final result with a EmployeeTO transfer object.

Step 4: Modified JUnit class

The results will now be tested against the returned transfer objects. Therefore, there are modifications in the test methods.

public class EmployeeBusinessServiceImplTest extends TestCase { private IEmployeeBusinessService empBusiness; private Map salaryMap; List expResult; // all methods not shown in the listing remain the // same as in the previous example private void initExpectedResult() { expResult = new ArrayList(); EmployeeTO to = new EmployeeTO(2,"John",46.11); expResult.add(to); } /** * Test of getEmployeesWithinSalaryRange method, of * class com.bea.dev2dev.business. * EmployeeBusinessServiceImpl */ public void testGetEmployeesWithinSalaryRange() { List result = empBusiness. getEmployeesWithinSalaryRange(salaryMap); assertEquals(expResult, result); } public void assertEquals(List expResult, List result){ EmployeeTO expTO = (EmployeeTO) expResult.get(0); EmployeeTO actualTO = (EmployeeTO) result.get(0); if(!expTO.equals(actualTO)){ throw new RuntimeException("** Test Failed **"); } } }

Benefits

The advantages of Spring's JDBC framework are clear. I have made significant gains and reduced the DAO methods to only a few lines of code. The code is no longer fragile thanks to out-of-the-box support for named parameter bind variables and the separation of transfer object population logic in mappers. The perennial problems of resource leakage and error handling are no longer cause for concern.

The benefits of Spring JDBC should encourage you to move your existing code to this framework. This article hopefully will help guide you in this endeavor. It will help you to be armed with some tools and knowledge on Refactoring. For example, in case you have not adopted the P2I Extract Interface, refactoring can be used to create interfaces from existing DAO implementation classes. Apart from this, take a look at this article's references for additional pointers.

Download

You can download the source code used in this article.

Summary

In this article I have shown you the basics of the Data Access Object(DAO) design pattern and discussed the pros and cons associated with it. Spring DAO or the JDBC framework was introduced to address the demerits of traditional DAO. Then, the fragile DAO code was amended with named parameter support provided out of the box by the Spring framework. Finally, the callback feature demonstrated how the behavior of the framework can be altered at specified points.

References

Core J2EE Patterns: Data Access Object (Sun Developer Network) - provides a detailed description of the DAO design pattern
Spring DAO Framework - the official Spring DAO documentation
Spring Integration with WebLogic Server (Dev2Dev) - a look at how Spring is integrated with WebLogic Server
WebLogic 8.1 Datasource Configuration (documentation) - this document provides a step-by-step guide for configuring datasources using the Administration console
Refactoring - this site explains refactoring basics and catalogs all the refactorings detailed in Martin Fowler's book, Refactoring: Improving the Design of the Existing Code; this site also contains a list of tools that can be used for refactoring

SOA Practitioners' Guide

2007-07-10T18:12:00.000+05:30

07/10/2007

SOA is relatively new, so companies seeking to implement it cannot tap into a wealth of practical expertise. Without a common language and industry vocabulary based on shared experience, SOA may end up adding more custom logic and increased complexity to IT infrastructure, instead of delivering on its promise of intra and inter-enterprise services reuse and process interoperability. To help develop a shared language and collective body of knowledge about SOA, a group of SOA practitioners created this SOA Practitioners' Guide series of documents. In it, these SOA experts describe and document best practices and key learnings relating to SOA, to help other companies address the challenges of SOA. The SOA Practitioners' Guide is envisioned as a multi-part collection of publications that can act as a standard reference encyclopedia for all SOA stakeholders.

The guide is available in three parts:

SOA Practitioners Guide Part 1—Why Services-Oriented Architecture? This guide provides a high-level summary of SOA.
SOA Practitioners Guide Part 2—This guide covers the SOA Reference Architecture, which provides a worked design of an enterprise-wide SOA implementation with detailed architecture diagrams, component descriptions, detailed requirements, design patterns, opinions about standards, patterns on regulation compliance, standards templates and potential code assets from members.
SOA Practitioners Guide Part 3—This guide introduces the Services Lifecycle and provides a detailed process for services management though the service lifecycle, from inception through to retirement or repurposing of the services. It also contains an appendix that includes organization and governance best practices, templates, comments on key SOA standards, and recommended links for more information.

Download

Download the SOA Practioner's Guide Part 1 (PDF, 476K).
Download the SOA Practioner's Guide Part 2 (PDF, 1.2MB).
Download the SOA Practioner's Guide Part 3 (PDF, 951K).

Resources

Arch2Arch
Dev2Dev's Service Oriented Architecture product center.

Complete article at: SOA Practitioners' Guide

National Geographic Channel strikes again...mind blowing!

2007-05-29T17:57:00.001+05:30