Customer Relationship Management (CRM)
The Technical "Know-How"
Ready to Use Interactive DAO - Intelligent and Dynamic
Data Access Object (DAO) is used to abstract and encapsulate all access to the data
source. The DAO manage the connection with the data source to obtain and store data. Regardless
of functionality and persistence, DAO are dummy data access objects.
Our view of Data Access Object (DAO) is that of human cardiovascular system, where the
blood circulate and transport nutrients, oxygen to nourish the body. There are different
types of blood cells.
Like blood cells, data run through the system and data are transformed and handled by
number of hands-processes. We are giving DAO Design Pattern a boost of intelligence and
make DAO more dynamic. Our Intelligent DAO will handle the following:
• Data (persistence) - get and set
• Answers to requests - methods calls
• Asks questions and scores the answer based on Dynamic Business Rules - methods calls
• Input data check
Let us look at the following types of DAO:
Business Object (BO) will be using Personal DAO to create the JSP. These JSP are created using
templates stored in the templates repository. Based on CRM services (with different languages
index) and Personal DAO, our data will be going out in the JSP page only and no data coming in to our system.
BO will receive page forms fields from handler servlets and check them against DAO. BO may
request more information or the correct form's fields values from the servlets handler by
passing back a web page with the requested fields values. Finally, BO pass data to Database
Services as: HTML forms, files, or any format.
Proxy Servlets on the proxy server tier will have access to our database services and receive security DAO.
The proxy servlets would go through the HTTP request values (including cookies) and call DAO methods. the Servlets
would call Security DAO methods and get a security score based on Security Dynamic Business Rules. The servlets
would be using the security score check against the Security Dynamic Business Rules. Based on the security
score, proxy servlets may deny service, ask more security questions, send a text message with a code to client
client's mobile, do other processes or call the servlets on the handler
tier to create the BO. This keeps security checks current, dynamic and no access to our system data except
through proxy servlets calls. The proxy servlets would be the only caller to handler tier servlets. The handler
servlets would be the only ones which create the BO. The BO are the only one that use Personal DAO.
For example, proxy servlets would be using security DAO and doing the following:
// local to the proxy servlets doPost() method called.
// Security Weights are stored in either Security Business Rules files
// These Security Weight files can be edited by the system admin.
// Each security check is based on the security weight given and stored in the security files.
// All these security checks weights are added and return a security score.
// Such security score would be used to run a number of security processes.
int localSecurityScore = localSecurityDAO.getSecurityScore();
case XX_123: do_xyz();
case XX_DENY_SERVICE: denyService();
These check calls would help make our system intelligent based the percentage of security success
score. Security weigh values can change plus the number of security checks in DAO and proxy servlets
can increase or decrease based on the situations, running system or events.
Our security system would be dynamic to handle different level security with different situations.
Refactoring would be done on the DAO and or local methods in the proxy servlets for any new security
changes. The Security Business Rules files would give the system the dynamic ability to change on the run.
Each DAO has the code to report exceptions, errors and logging. Proxy Servlets would be our first security check point.