We are currently not using any direct access to LDAP since all our user data
(except the user DN and UID which servers as the connecting key) are
currently in the RDBMS, represented by a BMP EJB called "User".
Nevertheless we will need write access to the LDAP as well since we want to
be able to add users directly from the application. Therefore we want to try
to extend the BMP code of "User" to partly connect to the LDAP, which makes
the actual place of storage transparent. In my opinion this is the most
EJB-like way.
Christoph
-----Original Message-----
From: Mike Clark [mailto:[EMAIL PROTECTED]]
Sent: Donnerstag, 7. September 2000 03:27
To: [EMAIL PROTECTED]
Subject: Re: LDAP access
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".
===========================================================================
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".
