Here are my notes from some internal design work on PD2.0, the primary goals are:
- Simplify configuration, this will likely involved a custom Spring namespace handler to provide a more complete XML configuration language.
- Improve lookup speed, adding in an ExecutorService to allow for parallel lookup of attributes from various sources.
- Simplify the API, provide a try criteria API for complex searches in addition to the ability to lookup attributes for a single user.
Secondary goals:
- Add JMX monitoring of performance of each attribute source.
QUESTIONS
# are attribute names case insensitive? YES according to PD1.5 behavior
api - public interface
* need to think/design the query builder API, something fluent would be good
** http://static.springsource.org/spring-ldap/site/apidocs/org/springframework/ldap/filter/package-frame.html
* do we need an Attribute class or are Attributes just Strings?
*
*
Complex queries and multiple attribute sources
* default root query object ORs its parts together?
* break root query object up by OR clause?
* the problem:
** Given a query like (firstName=Jane && (isStudent=Y || lastName=Doe))
** How do we handle sources that do not support all of the attributes in the query?
*** do a multi pass query, query sources that support all attributes first
*** query sources that support a subset of the attributes second, during merge filter these in code using the attributes that were not passed to the source
*** query non-searchable sources
General Query Logic
* attribute query
** ex: by username, [foo=bar, name=smith, ....]
** Run MS & PS sources
*** turn map into OR() criteria for MS
** Run S sources once per existing result
* criteria query
** ex: (firstName=jane && (lastName==smith || lastName=doe))
** Run MS sources
*** merge results
** Run PS sources
*** merge results
** Run S sources once per existing result
attribute source classes - how do we tell/config the difference?
* fully searchable (MS) - CriteriaSearchAttributeSource
** uses a query template (supports arbitrary logic)
** ldap or primary use directories go here
* partial searchable (PS) - SimpleSearchAttributeSource
** uses named placeholders but still can return multiple people for one query
** small associated sources go here
* single-person only (S)
** will only ever return a single result ... is this useful?
** in=memory sources like for shib go here
spi - what code in support implements to provide data
core - big ugly guts
* core code that does
** dependency tree calc of sources
** determine query order and potential for parallelism, probably better to figure it with always parallel and having "block" spots that wait for other sources to complete
** caching of results from each source
** handling of query timeouts
** merging results from various sources
** mapping attribute names from the API side to the SPI side
** jmx metrics for per-source usage & performance
** primaryId
*** Used when a find person by primary id query is run
*** Used to merge data from multiple sources (each result must have a primaryId set)
* add a list of AttributeSourceFilter
** these are called in order (sorted by ordered)
** if any filter returns false the filtered source is not executed
** filterchain style API that allows for modification of search?
* dependency tree calculation on configured attribute sources
** needs to fail to init if something is wrong with the tree
** this probably needs to be calculated and cached for each query since the tree will look different every time based on the input
* caching of results - part of XML config support
** for each configured source, set cache name or reference to Ehcache bean
** optional cache name/ref for misses
** optional cache name/ref for exceptions
* query timeout - part of XML config support
** set maximum wait for query result
** set behavior on timeout? (ignore, fail)
* merge behavior - part of XML config
** does it work for each source to have a "prepend/append/overwrite" flag?
** if so we probably need support for Spring's Orderable on the SPI impl
* attribute name mapping - part of XML config support
** for each configured source, option to allow for saying api attr "username" is actually "uid" in this spi
* attribute lists
** - in the config are these the PD side or the source side of the attr mapping?
** - at least one required or optional search attribute must be specified
** required search
*** ALL of these attributes must be include in a query for this source to be able to run the query
** optional search
*** This plus the required set make up the collection of attributes that can be used to search, attributes outside this set are ignored
** available return
*** The list of attributes the source returns, this is a best-effort set and the source may return more attributes than are named in the set
support
* attribute sources
** jdbc (MS,MP,S)
*** single row
*** multi row
** ldap (MS,MP,S)
** xml (MS)
** request attribute (S)
* filters
** regex
** spel