geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Davanum Srinivas <d...@yahoo.com>
Subject RE: [jndi] Have we found a JNDI impl yet?
Date Thu, 28 Aug 2003 18:04:57 GMT
Alex,

Which mailing lists are you using for discussion?

-- dims

--- Alex Karasulu <aok123@bellsouth.net> wrote:
> The current architecture has a primitive server side LDAP JNDI provider
> which is about 70-80% functional.  The provider directly accesses entries
> within the backend apparatus within the server.  When contexts are
> initialized they represent an instance/point of access (hence a context)
> into the directory information tree of the server bypassing the LDAP
> protocol stack.
> 
> In the new architecture, to be completed by mid October, the JNDI provider
> is at the core of the server's backend apparatus and shall be completed by
> then.  The server side JNDI LDAP provider will wrap something we call a
> nexus that attaches several databases each with a suffix in the namespace to
> a central point in the server.  The nexus performs name based routing to the
> backend that has jurisdiction over the region of the namespace specified by
> its suffix.  Anyway this apparatus is wrapped by JNDI.  The JNDI becomes the
> only way to enter the nexus and hence a target backend in the new
> architecture.  The JNDI is thus a shell around the backend subsystem of the
> server.  All orthogonal services implemented as Interceptors enable things
> like triggers, and change notification between calls made by the JNDI
> provider on the nexus.  This is how we introduce new services into JNDI
> calls on our provider.
> 
> There are two ways I can immediately conceive of in which this code can be
> leveraged to enable a persistant java:comp/env namespace for Geronimo.  But
> first consider this.  There may be areas where Geronimo will need to access
> and search over persistent data without having to bring this information
> into memory - this requires the industrial power of database indexing.
> Geronimo's configuration is a perfect candidate for storage in the directory
> - it will most likely be hierarchical in nature and very fitting.  Another
> excellent possibility is the use of the embedded server as the foundation
> for a security subsystem.  With that in mind lets just look at the way in
> which we can just enable the java:comp/env namespace while using LDAPd code.
> 
> First you can build over the LDAP namespace using it as a hierarchical
> relational database to manage environment data.  A java:comp/env namespace
> could be implemented using another JNDI provider to wrap the LDAP provider
> which has the super set of JNDI functionality (Context, DirContext, and
> LdapContext).  The wrapper provider would simply transform operations into
> the LDAP namespace according to the designed DIT structure and the schema
> used for java:comp/env objects.  The neat thing is you would have the power
> of search to find anything you needed very rapidly.  Much faster than a
> non-indexed solution - you're getting the power of a database at your
> disposal this way.  If you go this route then other aspects like
> configurations can also be stored in different areas of the directory
> information tree.  Also LDAP replication can be used to replicate your
> environment and configuration information for clustering in the future.  I
> would recommend this approach.  Although you don't expose all the LDAP
> functionality you can still leverage it under the hood of the java:comp/env
> provider to make it extremely fast.  I can help write this or add Geronimo
> developers to the LDAPd project to make it come to fruition.
> 
> The other approach involves the generalization of the Backend interface to
> store any kind of entry that does not necessarily need to be an entry within
> the LDAP namespace: see the attached xref file for the Backend interface.
> This way the backend apparatus is a generalized entry storage subsystem that
> could be used for any kind of namespace - directory enabled or otherwise.
> 
> Noel Bergman and I are in the process of discussing these details and anyone
> from the Geronimo team is welcome to join us.  Basically we reduce the JNDI
> methods into a minimal set of storage oriented operations very close in
> nature to the methods on Context and its subclasses.  This reduced
> instruction set if you could call it that is extremely simplified enabling
> storage for entries in any namespace.  The nexus multiplexes different
> backends for different namespaces almost federating them.
> 
> If a generalized provider with a pluggable NameParser is written then the
> provider can theoretically be used for any namespace.  Think of the concept
> as miniature framework for JNDI to enable storage and retrieval without the
> pain of having to implement all those methods on the Context interface and
> its subclasses.
> 
> These concepts are at the stage where new comers can join the conversation
> with a minimal learning curve to rapidly be able to participate.  We would
> welcome the collaboration to enable both projects to progress together.
> 
> Good luck & BU,
> Alex Karasulu
> 
---------------------------------

View Javadoc1   /*2    * $Id: Backend.java,v 1.11 2003/08/18 02:06:16 akarasulu Exp $3   
*4    *
-- (c) LDAPd Group                                                    --5    * -- Please refer
to
the LICENSE.txt file in the root directory of      --6    * -- any LDAPd project for copyright
and
distribution information.      --7    *8    */9   10  package ldapd.server.backend ;11  12
 13 
import javax.naming.Name ;14  import javax.naming.NamingException ;15  import
javax.naming.NamingEnumeration ;16  17  import javax.naming.directory.Attributes ;18  import
javax.naming.directory.SearchControls ;19  import javax.naming.directory.ModificationItem
;20  21 
import ldapd.common.filter.ExprNode ;22  23  24  /***25   * The Backend interface represents
the
operations that can be performed on a 26   * Directory Information Base (DIB) which stores
and
manages the entries in a 27   * Directory Information Tree (DIT).28   *29   * @author <a
href="mailto:aok123@bellsouth.net">Alex Karasulu</a>30   * @author $Author: akarasulu
$31   *
@version $Revision: 1.11 $32   */33  public interface Backend34  {35      /***36       * Deletes
a
leaf entry from this Backend: non-leaf entries cannot be 37       * deleted until this operation
has been applied to their children.38       *39       * @param a_dn the normalized distinguished
name of the entry to delete40       * from this Backend.41       * @throws NamingException
if
there are any problems42       */ 43      void delete( Name a_dn ) throws NamingException
;44  45 
    /***46       * Adds an entry to this Backend.47       *48       * @param a_updn the user
provided distinguished name of the entry49       * @param a_ndn the normalized distinguished
name
of the entry 50       * @param an_entry the entry to add to this Backend 51       * @throws
NamingException if there are any problems52       */53      void add( String a_updn, Name
a_ndn,
Attributes an_entry ) 54          throws NamingException ;55  56      /***57       * Modifies
an
entry by adding, removing or replacing a set of attributes.58       *59       * @param a_dn
the
normalized distinguished name of the entry to modify.60       * @param a_modOp the modification
operation to perform on the entry which61       * is one of constants specified by the DirContext
interface:62       * <code>ADD_ATTRIBUTE, REMOVE_ATTRIBUTE, REPLACE_ATTRIBUTE63    
  * </code>.64
      * @param a_mods the attributes and their values used to affect the 65       * modification
with.66       * @throws NamingException if there are any problems67       * @see
javax.naming.directory.DirContext68       * @see javax.naming.directory.DirContext.ADD_ATTRIBUTE69
      * @see javax.naming.directory.DirContext.REMOVE_ATTRIBUTE70       * @see
javax.naming.directory.DirContext.REPLACE_ATTRIBUTE71       */72      void modify( Name a_dn,
int
a_modOp, Attributes a_mods )73          throws NamingException ;74  75      /***76       *
Modifies an entry by using a combination of adds, removes or replace 77       * operations
using a
set of ModificationItems.78       *79       * @param a_dn the normalized distinguished name
of the
entry to modify.80       * @param a_mods the ModificationItems used to affect the modification81
 
    * with.82       * @throws NamingException if there are any problems83       * @see
javax.naming.directory.ModificationItem84       */85      void modify( Name a_dn, ModificationItem
[] a_mods ) 86          throws NamingException ;87  88      /***89       * A specialized form
of
one level search used to return a minimal set of 90       * information regarding clikd entries
under a base.  Convenience method 91       * used to optimize operations rather than conducting
a
full search with 92       * retrieval.93       *94       * @param a_base the base for the
search/listing95       * @return a NamingEnumeration containing objects of type 96       *
<a
href="http://java.sun.com/j2se/1.4.2/docs/api/97       *
javax/naming/NameClassPair.html">NameClassPair</a>.98       * @throws NamingException
if there are
any problems99       */100     NamingEnumeration list( Name a_base ) throws NamingException
;101  
  102     /***103      * Conducts a search against this Backend.104      *105      * @param
a_base
the normalized distinguished name of the search base106      * @param a_filter the root node
of
the filter expression tree107      * @param a_controls the search controls108      * @throws
NamingException if there are any problems109      * @return a NamingEnumeration containing
objects
of type 110      * <a href="http://java.sun.com/j2se/1.4.2/docs/api/111      *
javax/naming/directory/SearchResult.html">SearchResult</a>.112      */113     NamingEnumeration
search( Name a_base, ExprNode a_filter, 114         SearchControls a_controls ) throws
NamingException ;115 116     /***117      * Looks up an entry by distinguished name.  This
is a
simplified version 118      * of the search operation used to point read an entry used for
119    
 * convenience.120      *121      * @param a_dn the normalized distinguished name of the object
to
lookup122      * @return an Attributes object representing the entry123      * @throws
NamingException if there are any problems124      */125     Attributes lookup( Name a_dn )
throws
NamingException ;126 127     /***128      * Fast operation to check and see if a particular
entry
exists.129      *130      * @param a_dn the normalized distinguished name of the object to
check
for131      * existance.132      * @return true if the entry exists, false if it does not.133
    
* @throws NamingException if there are any problems134      */135     boolean hasEntry( Name
a_dn
) throws NamingException ;136 137     /***138      * Checks to see if an entry is a suffix.139
   
 *140      * @param a_dn the normalized distinguished name of the entry to test141      *
@return
true if the entry is a suffix, false if it does not.142      * @throws NamingException if
there
are any problems143      */144     boolean isSuffix( Name a_dn ) throws NamingException ;145
146  
  /***147      * Modifies the entry by changing its Relative Distinguished Name (RDN) and148
    
* optionally removing the old RDN attribute.149      *150      * @param a_dn the normalized
distinguished name of the entry to modify the151      * RDN of.152      * @param a_newRdn
the new
RDN of the entry specified as an equality 153      * assertion value pair with the following
syntax: <attribute> = <value>.154      * @param a_deleteOldRdn boolean flag which
removes the old
RDN attribute155      * from the entry if set to true, and has no affect if set to false.156
    
* @throws NamingException if there are any problems157      */158     void modifyRdn( Name
a_dn,
String a_newRdn, boolean a_deleteOldRdn )159         throws NamingException ;160 161     /***162
 
   * Transplants a child entry, to a position in the DIT under a new parent 163      * entry.164
 
   *165      * @param a_newParentDn the normalized distinguished name of the new parent166
     *
to move the targeted entry to.167      * @param a_oldChildDn the normalized distinguished
name of
the older child168      * Dn representing the child entry to move.169      * @throws
NamingException if there are any problems170      */171     void move( Name a_oldChildDn,
Name
a_newParentDn ) 172         throws NamingException ;173 174     /***175      * Transplants
a child
entry, to a position in the DIT under a new parent 176      * entry and changes the RDN of
the
child entry which can optionally have177      * its old RDN attributes removed.178      *179
    
* @param a_oldChildDn the normalized distinguished name of the old child180      * Dn representing
the child entry to move.181      * @param a_newParentDn the normalized distinguished name
of the
new parent182      * to move the targeted entry to.183      * @param a_newRdn the new RDN
of the
entry specified as an equality 184      * assertion value pair with the following syntax:
<attribute> = <value>.185      * @param a_deleteOldRdn boolean flag which removes
the old RDN
attribute186      * from the entry if set to true, and has no affect if set to false.187 
    *
@throws NamingException if there are any problems188      */189     void move( Name a_oldChildDn,
Name a_newParentDn, String a_newRdn,190         boolean a_deleteOldRdn ) throws NamingException
;191 }192 193 

---------------------------------
This page was automatically generated by Maven


=====
Davanum Srinivas - http://webservices.apache.org/~dims/

Mime
View raw message