Alex,

Which mailing lists are you using for discussion?

-- dims

--- Alex Karasulu <[EMAIL PROTECTED]> 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:[EMAIL PROTECTED]">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/

Reply via email to