What are Stored Procedures in LDAP?

The closest thing to a Stored Procedure in LDAP is an Extended Operation. This is how the outside world would have access to procedures defined within the server. From this we can infer something: stored procedures are static operations. They can also have return values.

Java as the Native SP Language

Rather than complicate things with scripting languages and frameworks like BSF to implement stored procedures we'll keep this first round really simple. Java is a natural fit for us too so I'm not going to worry about leaving scripting languages out of the picture. Also with ClassLoaders we can dynamically install and load new Java classes carrying stored procedures.

Storing Classes within the DIT

Classes will be stored within entries in the DIT. These entries like others can be protected by ACI to prevent exposure. All classes stored in the DIT will not be for stored proc entry points. Some classes will be supporting classes, and some used to form libraries. So before we start talking about stored procedures we need to consider code in the DIT and how it might be used.

We already defined a simplistic objectClass and attributeTypes for representing a class within an entry. A very primitive ClassLoader (CL) was able to load classes on demand by searching for them within the DIT. We need to go a step further though. Every user will have their own view of the DIT with ACI in effect, so every user will need to execute procedures in their own CL. A user's CL needs to pull in all classes in the DIT visible to the user. This CL can be used to execute stored procedures.

Thus the user specific CL needs to load the visible classes (seen by a user) as they are needed to execute procedures. This could really slow things down though. Some caching may be in order here but how that's to be done properly and efficiently is yet to be determined.

Code Security and Class Conflicts

As we pointed out code is stored in the DIT and ACIs are used to control the code entries visible to users. Hence this changes the classes loaded into different user CLs. Note that multiple versions or copies of the same class may exist within the server. This is ok. Conflicts can result as they do with standard fs based classloaders. The fact that each user has its own CL helps limit the colliosions.

We proposed some ACIItem extensions to make sure we can easily and efficiently isolate code across users. The new creator and notCreator userClasses have been proposed here: ACIItem Extensions. With these userClasses we can define a single ACIItem in a subentry at each ACSA with a subtreeSpecification refinement that makes javaClass entries only visible to their creators.

Code reuse will also come into the picture here. The administrator may expose some classes as libraries that users can build on. Making these classes visible to all users may in turn result in some conflicts. For example users may load libraries of a newer version. What will be our policy here? Should this policy be something that should be decided by the Administrator? Should users be able to override this policy?

Searching and Search Order for Classes

We are not going to constrain users and administrators to have to maintain classes within a specific region of the DIT. javaClass entries can reside anywhere within the DIT, within any namingContext. This makes searching for these entries a bit inefficient since the RootDSE must be used and multiple searches must be conducted on each namingContext until a javaClass is found.

Convensions are good but admins should have options. By default the java subsystem will exhaust the possibilities. We will allow administrators to configure the java subsystem by specifying a specific search order for classes. This search order is a list of search operations. Under the ou=configuration,ou=system area we can manage this list of operations. Basically the admin can specify each search operation as a LDAP URL to search under for javaClasses. Perhaps each URL can be prefixed with an 'insert' directive that defines how it is inserted into the list of search operations.

User profiles can also manage this configuration by inserting their own search operations into the list. The resultant list of search operations is used by the user's ClassLoader to discover classes within the DIT. Users should be able to see the search order of the system so they can override or inject their own bypass. This may be a good mechanism for users to control situations where libraries and classes in the system might conflict with their own version. Perhaps the CL search order for the system should be published either in the RootDSE or exposed in the ou=system configuration area.

Stored Procedure Call Specification (This is no longer valid.)

As stated before, a stored procedure is close to an LDAP extended operation. However, we will not register a new extended operation for each stored procedure. Instead of that, we'll have a generic Stored Procedure extended operation where the stored procedure to be called will be specified in the parameter list of the extended operation. (Of course this does not prevent some stored procedures to be published as standalone extended operations.) Here is the proposed stored procedure specification in ASN.1 format:

Stored Procedure Execution Request Value

BER

0x30 LL 0x04 LL abcd [ [ 0x31 LL 0x12 LL abcd 0x30 LL ( 0xc04 LL abcd... [ 0x0A 0x01 0x0[0..2] ] ) [ 0x30 LL 0x30 LL [ 0x04 LL abcd ] 0x84 LL abcd ] | [ 0x30 LL 0x30 LL [ 0x04 LL abcd ] 0x84 LL abcd ] ]

The State Machine

Poseidon for UML 4.2 project file

Explanations

The language field is used to specify the implementation language of stored procedure to be called. This field allows the server to provide any kind or more than one kind of stored procedure implementations. We'll support compiled Java SPs as default and support forJython is scheduled for after 1.0 release.

The procedure field is used to specify the fully qualified name of the procedure to be called. An example can be "For.Bar.proc".

The parameters field is used to specify a list of parameters (with their types and values) to be given to the procedure to be called. Type information is needed to enable maximum implementation generalization. Encoding these fields with OCTETSTRING also helps generalization. Interpreting these fields' values are up to the server. By default we'll require type field to include fully qualified class name of a Java type and we'll require value field to include a string representation of the parameter value if it's a primitive one and as byte[] if it's a complex Java object.

The return value of stored procedures will be provided by extended operation responses with same semantics mentioned above.

As an implementation tip, what we're doing here is like adding reflection capability to our server to call stored procedures. Thinking in terms of Java reflection mechanish helps us better design the system here.

According to definitions here, stored procedures in our server will enable users to define and use their own standard extended operations. We'll explore new usage scenarios of stored procedures like Triggers, Task Scheduling in the near future.

Our approach provides independence of any client, any server and any language implementation which will make us write a good IETF RFC about the enhancement.

Security

http://www.oracle.com/technology/oramag/oracle/03-jul/o43devjvm.html