in black and white
Main menu
Share a book About us Home
Biology Business Chemistry Computers Culture Economics Fiction Games Guide History Management Mathematical Medicine Mental Fitnes Physics Psychology Scince Sport Technics

More Java Pitfalls Share Reactor - Daconta M,C.

Daconta M,C. More Java Pitfalls Share Reactor - Wiley publishing, 2003. - 476 p.
ISBN: 0-471-23751-5
Download (direct link): morejavapitfallssharereactor2003.pdf
Previous << 1 .. 81 82 83 84 85 86 < 87 > 88 89 90 91 92 93 .. 166 >> Next

These authentication and personalization activities raised many questions about data exposure and integrity, along with proper delivery and storage mechanisms for that information. Some, specifically, database vendors, suggested that role and preference information should be stored in a database. Others suggested that this information should be collected in an LDAP directory server. For enterprise system deployments, both can be implemented, but the proper manner to store and retrieve profile and personalization information would be a combination of both. An LDAP directory should be used to house fairly static information—namely, items that don't change all that often—and user role information. Databases should be used for dynamic data, which means data that changes often.
From an architectural perspective, Relational Database Management Systems (RDBMSs) are flat tables with no mechanisms that reflect their organizational structure, while LDAP directories render data in treelike structures that allow users to retrieve organized data and view their spatial relationships. LDAP directories were designed for high-speed read operations and high availability through replication. Migration of dynamic data to an LDAP directory server would be a bad idea because that would be forcing the protocol to perform operations that it was not designed to do.
Two differences between LDAP directories and database systems are how they retain data and perform security activities. RDBMSs typically use table-oriented read/write operations, while LDAP directories concentrate on attribute-oriented security. LDAP directories are constructed to work with multivalue attributes, while traditional relational databases would have to perform SQL join operations to achieve the same functionality. This join-ing of tables in database operations generally hampers performance.
Since LDAP directories were designed for low-throughput and high-speed operations as well as high availability through replication, they've been known to produce incorrect answers from their repositories because of transactional consistencies during write and replication activities. Aberrations like these can be tolerated for storage and retrieval of simple queries, but not with mission-critical data, and that is why data transactions in LDAP directories should be avoided.
236 Item 27
RDBMS support for ACID transactions (i.e., transactions that support atomicity, consistency, isolation, and durability) make databases the preferred choice for handling important data. Their implementation ensures predictability and reliability of data transactions. The hierarchical nature of LDAP directories often models real-world data better than flat files in relational databases. It just makes sense to store dynamic data in RDBMSs because they are more flexible and reliable in handling transactions, especially commit and rollback operations.
Personalization is generally considered a dynamic and personalized content delivery system that promotes self-service activities, which in turn strengthens user relationships. The objective of personalization is to deliver pertinent and targeted content to users so that user retention can be maintained and strengthened. When users talk about personalization, they often confuse it with customization. Customization should be considered a subset of personalization, because personalization dictates what content the user has access to and customization allows users to whittle down and modify the presentation of that data. On many applications, specifically, portals, users can customize visualization preferences (what portlets do I want to view? where I want to view them on the page?). More often than not, personalization is based on predetermined role information or previous clickstream detections. In some instances, personalization is based on information explicitly provided by users who are confident in their application's security to provide personal information like salary information or buying preferences. With personalized data, applications can create user communities and matching agents can target content to users based on that information.
To demonstrate how an LDAP directory and an RDBMS can be used in tandem to deliver personalized content, a sample application was developed that retrieves relatively stable profile data in an LDAP directory and stores more dynamic data in a relational data store. The authentication and personalization process is illustrated in Figure 27.1.
Client Layer
il cC
¦ =2— HTTP Server App. |jdbc Profile Data
Web Layer
EIS Layer
Upon authentication, all user profile information in the LDAP database is passed back and persisted in the database store
All transactional information obtained from the user during operations is persisted also
Figure 27.1 LDAP authentication.
Transactional LDAP-Don't Make that Commitment 237
The ControllerServlet class in Listing 27.1 implements the Front Controller pattern to control all requests through a single servlet application and dispatches requests based upon user role information derived from an LDAP directory server. If a user is recognized as a valid entry in the LDAP directory, that user will be forwarded to the Web page that reflects his or her role.
Previous << 1 .. 81 82 83 84 85 86 < 87 > 88 89 90 91 92 93 .. 166 >> Next