directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alex Karasulu" <akaras...@apache.org>
Subject Re: [ApacheDS] Comments on Stored Procedure Implementation (was Re: [Roadmap]Apache Directory Server 2.0 Roadmap proposal)
Date Fri, 28 Sep 2007 21:53:16 GMT
On 9/28/07, Ersin Er <ersin.er@gmail.com> wrote:
>
>
>
> On 9/28/07, Alex Karasulu <akarasulu@apache.org> wrote:
>

SNIP ...

3). SP Invocation: Procedure Qualification
> >
> > Right now we have an ExtendedOperation used to invoke stored procedures
> > using qualified names based
> > on the namespace of the procedure language.  This is a questionable
> > mechanism since it requires the user
> > to know what the language of the implementation of the procedure is and
> > how to qualify the procedure in that
> > language.  If a universal call specification is devised it can link
> > language independent invocation requests to
> > the proper language specific method.  It would then be the job of the
> > writer to add this call spec and not the
> > job of the user to track which language the stored procedure was
> > implemented in.
> >
>
> This leads to us towards implemeting something like web services stack for
> LDAP. We need to be careful about making this really simple. And I think we
> should not focus on the external invocation specification during the initial
> standardization effort.
>

I agree and disagree :).  First I disagree that this is like a web services
stack for LDAP because we're keeping it
simple with primitive static bindings for parameters.  I would not propose
that we go all the way with devising dynamic
bindings for complex types or structures.  If we did then yes you would be
right.

I agree with keeping it simple by managing the scope and I think it's
inherent in the original proposal for bindings
to primitive types and things like Dates etc.

LDAP stored procedures are useless unless they treat all invokers alike
while removing the need for clients to be aware of
the implementation language of the stored procedure doing the work.  So this
absolutely must be addressed and I have
already started on this and from my observations this is not a monumental
task to achieve.

4). SP Invocation: Parameter Bindings
> >
> > This is connected to 3.  The same extended operation allows invokers to
> > provide parameters to the stored
> > procedure.  It would not be fun to have SPs without parameters.  This
> > opens up a slew of problems for us.
> > First we need to define now a language independent means to specify
> > parameters.  ASN.1 does this nicely
> > so we can leverage ASN.1 primitive types at first.  ApacheDS can easily
> > transform these types into the types
> > expected by the implementation language of the SP.  This however
> > requires some primitive type bindings and
> > the code to translate them.
> >
> > Right now the extended operation works with primitive Java types and
> > serialized objects (I think but Ersin can
> > confirm).  This makes it so a C client cannot really invoke a SP
> > implemented in Java unless it knows how to
> > serialize java objects into a byte buffer.  This is not really feasible
> > so we need to specify some type bindings
> > and use that instead of serializing objects.  We cannot expect invokers
> > from python, groovy, php, c, perl etc
> > to have to know anything about Java.  Invocation should not have be
> > language dependent to allow for maximum
> > flexibility.
> >
>
> As this is not an easy to solve problem quickly and as stored procedures
> are more important from the triggers point, we can focus on SP-Trigger
> integration more. Trigger Specifications allow you to inject operation
> specific parameters to stored procedures and determining the Java types for
> these parameters should be handled by an RFC alone.
>

Yes you are correct. These are not simple parameters however they are static
and will not change over time.  They simply
add to the number of static bindings to be supported.

I'm adding these details btw to a the first draft (version 00) of an IETF
> > draft submission.
> >
> > Alex
> >
>
>
> I think about the following drafts initially:
>
> LDAP Triggers: Representation and Abstract Model of Execution
> LDAP Stored Procedures - Representation
>

I have started on these two as one draft since the abstract model is the
representation IMO.

LDAP Stored Procedures - Abstract Model of Invocation by LDAP Triggers
> Java Language Bindings for Java LDAP Stored Procedures Invoked by LDAP
> Triggers
>

These may be part of the draft for triggers.

Alex

Mime
View raw message