directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ole Ersoy <ole.er...@gmail.com>
Subject Re: Question on schema elements in documentation: OIDs for examples?
Date Sat, 21 Apr 2007 18:41:51 GMT
Hi Alex,

Wow - This sounds really cool.  Can you give us an
overview of this stuff?  :-)

Seriously - Thanks for all the elaboration.

I gotta hurry about and smack out this DAS (And the installer),
so I can help with this type of documentation
more.

These types of capabilities are right in line with
model driven development / SOA approaches, so I think
some serious bragging about them in the DAS Design
(and subsequent user ) Guide is in order as well.
I'll make sure it gets in there.

Cheers,
- Ole



Alex Karasulu wrote:
> Hi Ole, Stefan,
> 
> I just wanted to add some more information to this.  LDAP schema 
> according to the standard can
> be composed of the following kinds of entities which govern various 
> aspects of the schema
> controlling entries:
> 
> * Syntaxes
> * MatchingRules
> * AttributeTypes
> * ObjectClasses
> * MatchingRuleUses
> * DitStructureRules
> * DitContentRules
> * NameForms
> 
> In ApacheDS 1.5.0 and above we have some additional schema entities 
> specific to ApacheDS which
> were devised to facilitate the dynamic extension of the schema:
> 
> * Comparators
> * Normalizers
> * SyntaxCheckers
> 
> These atomic elements allow users to actually implement and load code 
> into the server to create
> new Syntaxes and MatchingRules.   They are the building blocks for 
> defining the behavior of Syntaxes
> and MatchingRules.
> 
> In traditional LDAP servers which lack these elements there was no way 
> to dynamically add new
> matchngRules or syntaxes without a restart if you could at all extend 
> the server to do so.  Basically
> you were stuck with the syntaxes and matchingRules hard coded into these 
> servers.  The protocol
> standards which define a grammar for specifying matchingRules and 
> syntaxes are extremely simple.
> They merely state that a matchingRule or syntax exists within the server 
> with an OID for it.  This is
> not enough to specify the behavior for these constructs.  For example a 
> syntax spec might look like
> so:
> 
> ( 1.3.6.1.4.1.1466.115.121.1.15 DESC 'Directory String' )
> 
> 
> As you can see there is not much to this.  It is merely a declaration 
> that the a syntax exists with an
> OID called 'Directory String'.  There is no information provided in the 
> specification on how to validate
> this syntax.  This is why so many legacy servers hard code the logic to 
> validate the common
> syntaxes.  This also means extending the syntaxes supported by these 
> servers is either impossible
> or require writing validation code using some proprietary interface for 
> it.  If at all possible this
> requires a restart and downtime.
> 
> I created the concept of a syntaxChecker for ApacheDS which has a simple 
> description that may
> include code to perform the validation.  Here's what the description for 
> a syntaxChecker looks like:
> 
> ( 1.3.6.1.4.1.1466.115.121.1.1 FQCN 
> org.apache.directory.shared.ldap.schema.syntax.ACIItemSyntaxChecker  )
> 
> or another form for it is ...
> 
> ( 1.3.6.1.4.1.1466.115.121.1.23 FQCN org.foo.BarSyntaxChecker  BYTECODE 
> 'abc2d7ae3453...' )
> 
> The first form references a class that is included in ApacheDS and 
> implements the SyntaxChecker interface
> which is pretty simple here:
> 
> *public* *
> interface* SyntaxChecker
> {
>     String getSyntaxOid();
>     *boolean* isValidSyntax( Object value );
>     *void* assertSyntax( Object value ) 
> *throws* NamingException;
> }
> 
> As you can see all a syntaxChecker does is announce the Syntax it 
> validates and has two methods
> to do the validation.  Once does a boolean check and the other does the 
> same check but throws an
> exception on a violation.
> 
> So in the first form the OID is really the OID of the syntax the 
> SyntaxChecker validates.  The FQCN
> is needed to load the class and add it to a registry for 
> syntaxCheckers.  The second form is very
> special in that it adds bytecode.  The syntax checker's bytecode is 
> loaded into the server and is
> then loaded into the jvm using a special classloader that searches the 
> schema partition for the
> class.  Once loaded an instance is created and added to the registry.  
> This way we can add new
> syntaxCheckers to ApacheDS on the fly without a restart.
> 
> Now after adding the syntaxChecker description to the server an 
> administrator can add the syntax
> description for the new syntax with the same OID.  ApacheDS will not 
> allow the addition of a syntax
> without the presence of a syntaxChecker with the same OID to validate 
> that syntax.
> 
> Does this make sense?
> 
> I won't go into matchingRules here but the concepts are similar.  
> MatchingRules unlike a syntax
> require the presence of a comparator and a normalizer for the OID of the 
> new matchingRule to
> add to the server.
> 
> In conclusion these ApacheDS specific constructs allow for the dynamic 
> extension of the server
> where schema is concerned without a restart.  Unlike other LDAP servers 
> you can add new
> matchingRules and syntaxes to the server on the fly and not worry about 
> down time.  I think this
> is a very powerful feature that differentiates ApacheDS over other 
> legacy servers.   Note that
> these same concepts of dynamic extension are applied to Triggers and 
> Stored Procedures which
> have now appeared in ApacheDS 1.5.
> 
> <ot-idea>
> Hmmm me thinks to me self that it might be a good idea to have an LS 
> plugin which can allow
> users to write these extension classes and load them into the server.  
> Write a SyntaxChecker
> and right click in the pkg browser to deploy it to a server 
> (connection).  How cool would that be?
> </ot-idea>
> 
> Eventually I think we're going to see LDAP evolve to the point where the 
> specifications need to
> support a language independent means to extend the schema.  I have a 
> feeling ApacheDS will
> drive this revolution to reform this dilapidated protocol.  After all 
> this was my original intent for
> starting the Directory effort here.  I think a handful of crazy yet 
> talented people in a community
> can achieve this.
> 
> Alex
> 
> On 4/20/07, *Ole Ersoy* <ole.ersoy@gmail.com 
> <mailto:ole.ersoy@gmail.com>> wrote:
> 
>     Hi Stefan,
> 
>     It looks really good.  I'll probably we frequenting that when I need
>     reminders.  :-)
> 
>     Also, I found Emmanuel's tip for browsing the Schema partition
>     (by adding an ou=schema connection) to LDAP studio really handy.
> 
>     I'm not done reading yet, but I started with this:
> 
>     =======================================================================
>     The schema of an LDAP server is comprised of object classes, attributes,
>     syntaxes and matching rules. Basically it defines which entries are
>     allowed within the server and how the server should handle them. In
>     contrast to the 1.0 release, ApacheDS 1.5.0 comes with a completely
>     redesigned schema subsystem. It allows to dynamically update the
>     schema,
>     for instance it is possible to create new attribute types or object
>     classes on the fly, i.e. without restarting the server.
>     =======================================================================
> 
>     Here's another attempt:
> 
>     =======================================================================
>     The schema of an LDAP server is a set of entries of the following types:
>     - ObjectClass
>     - AttributeType,
>     - Syntax
>     - MatchingRule
> 
>     The first three types of entries are used to the schema rules /
>     structure of other stored in the server.  ApacheDS 1.5.0 comes with a
>     completely redesigned schema subsystem. It enables dynamic schema
>     updates, like the creation of new AttributeType or ObjectClass entries
>     at runtime.
>     =======================================================================
> 
>     I still need to figure out MatchingRule entries...:-)
> 
>     I think the only thing that needed grammatic fixing was this part:
> 
>     =======================================================================
>     It allows to dynamically update the schema,
>     =======================================================================
> 
>     The rest is just a suggestion.
> 
>     Cheers,
>     - Ole
> 
> 
> 
> 
> 
> 
> 
> 
>     Stefan Zoerner wrote:
>      > Hi all!
>      >
>      > I have started a little text for newbies on how to add custom
>     elements
>      > to the schema with the help of the new schema subsystem of ApacheDS.
>      > First of all: I works fine to add elements with standard JNDI
>     methods,
>      > well done, Alex!
>      >
>      > My first attempts for the text can be found here:
>      >
>      >
>     http://cwiki.apache.org/confluence/display/DIRxSBOX/Add+your+first+elements+to+the+schema
>      >
>      >
>      > I plan to make this an introduction section to the schema topic
>     in the
>      > Advanced User's Guide of ApacheDS 1.5, although there is
>     obviously still
>      > some work to do. Any feedback on the current structure and state
>     of the
>      > section is therefore highly appreciated! I am a newbie on this schema
>      > subsystem as well.
>      >
>      > The section is build around an example of adding a custom
>     attribute type
>      > (numberOfGuns) and a custom object class (ship) to the schema in
>     order
>      > to add entries like this one for instance:
>      >
>      > dn: cn=HMS Victory,ou=ships,o=sevenSeas
>      > objectClass: top
>      > objectClass: ship
>      > cn: HMS Victory
>      > numberOfGuns: 104
>      > description: a ship of the line of the Royal Navy, built between
>     1759
>      > and 1765
>      >
>      > For adding numberOfGuns and ship to the schema I have to use
>     OIDs, but I
>      > think it is not worth to register them officially below
>      > 1.3.6.1.4.1.18060.0.
>      >
>      > Should I use obvious fun data like 9.9.9.9.9.1 and 9.9.9.9.9.2,
>     describe
>      > the idea of OIDs and that a user should normally obtain a unique
>      > starting point?
>      >
>      > Or should I use something which starts with 1.3.6.1.4.1.18060.0
>     and add
>      > it on the list. Perhaps we can add a branch for documentation
>     examples.
>      >
>      > What do you think?
>      > Greetings from Hamburg,
>      >     Stefan Zoerner (szoerner)
>      >
>      >
>      >
> 
> 

Mime
View raw message