If the intent is to simply lookup data (read-only), then I'd favor a simple
Java data access object wrapped in a session bean. Even if new data elements
will be bound into the JNDI namespace (read-write), it's probably not likely
that more than one user will need concurrent access to the same JNDI
sub-context. Therefore, an entity bean in this scenario is a bit heavy-handed,
in my opinion.
Mike
Brett McLaughlin wrote:
> Folks-
>
> Question for you:
>
> In a typical application scenario, data is stored in both a database(s)
> and directory server(s). Often, information is referenced from one to
> the other, as well. For example, consider an application that uses LDAP
> for authentication, permissions, and roles, but an RDBMS for information
> storage. The USERS table in the database might have a column, USER_DN,
> which stores the DN of the user in LDAP. So a user would login (through
> LDAP), authenticate (through LDAP), and then their information would be
> looked up in the database via their userDN.
>
> So the case for the database is simple - entity beans, nothing special.
> What I was curious about is what methods you guys are using for
> providing (obviously Java) access to the directory server. I see three
> main options:
>
> 1) entity bean (BMP) for LDAP
> 2) session bean for LDAP
> 3) standard Java object
>
> While the first is a bit clunky, the entity bean having lots of JNDI in
> it, and not really being able to rollback and so forth, there is a
> certain elegance in that it can help mask where the physical data is
> stored (i.e. what medium, LDAP or RDBMS)
>
> The second could be done through a facade bean "tunnelling" through to
> the entity beans used for the USERS table, but would also take care of
> LDAP. This could also hide the underlying data facilities used, but has
> the disadvantage of not allowing generic, atomic access to the LDAP
> structure. No one-to-one type mappings for the users, groups, and
> permissions.
>
> The third is the easiest, but the least analagous to the entity bean
> access going on for all other data.
>
> Thoughts?
>
> Thanks,
> Brett
>
> --
> Brett McLaughlin, Enhydra Strategist
> Lutris Technologies, Inc.
> 1200 Pacific Avenue, Suite 300
> Santa Cruz, CA 95060 USA
> http://www.lutris.com
> http://www.enhydra.org
>
> ===========================================================================
> To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
> of the message "signoff EJB-INTEREST". For general help, send email to
> [EMAIL PROTECTED] and include in the body of the message "help".
--
//////////////////////////////////////////////////////
//
// Mike Clark
//
// Clarkware Consulting
// Enterprise Java Architecture, Design, Development
//
// http://www.clarkware.com
// [EMAIL PROTECTED]
// +1.720.851.2014
//
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff EJB-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
