Customer Relationship Management (CRM)
Data Farm Inc.

The Technical "Know-How"
Home Executive Summary Investors Trade Secret Compression Encryption Data Streaming Business Intelligence
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
       Logging
       Errors
       Exception
       Security


Let us look at the following types of DAO:

       Personal
       Security


Personal 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.

Input data:
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.

Security DAO:
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.
       localSecurityDAO.checkIP (IP)
       localSsecurityDAO.checkURL(url)
       localSsecurityDAO.checkServerLocation (serverLocation)
       ...
       // 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();

       which(localSecurityScore)
       {

              case XX_123: do_xyz();
              ...
              case XX_DENY_SERVICE: denyService();
              default:
                     ...
       }

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.

       Facebook Facebook Facebook Facebook Facebook
Thinking in
Tiers
Data Access
Object
Interactive
Front
Zeros & Ones
Plus Math
Data and
Databases
Check List Issues
Mobile-Browsers Standardization Templates Conversion Index Performance FAQ
Cloud Intelligent JSP Template Indexing DAO-XML Security Clients
Server Personal Multiple
Languages
Encryption Tracing & Transformation Errors & Logging Future
Security &
Communication
Business Intelligent
Shopping Cart
Compression Data Structures Scalability
(Expandability)
Big Data
Business Transaction Ready to Use
DAO
  Internal &
External
Flexibility CRM
Data Refactoring Server Traffic   CLOB & BLOB Transparency End-to-End
Mapping & Farming       Encryption Availability Intelligence
Web Services       Compression Latency Marketing
New Technologies       Security Brainstorm (Team) Sales

About us Contact Site Map Support Privacy Terms All rights reserved