[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [provision] RE: Batch Lookup (was "Re: ReadOnlyProfile")
My perspective on this is being driven by the need to implement
an batch/occasionally-connected interface to an Attribute Provider (AP) that
uses SPML as the interface specification. The motivator for the “Read
Only” portion is that AP is fronting authoritative sources of data that
have existing processes in place for Attribute Management and as such
Updates/Deletes etc are permitted. The assumption in this case is that the “Attribute
Contract” that is supported by the AP is known and fixed.. i.e. There is a
finite set of attributes that are exposed via this interface and are advertised
via the listTargets operations At the same time, one of the items that came out of the Burton
Group discussions around SPML was that implementing a provider that that
supported all permutations of the ‘and’ or ‘or’ and ‘not’
operators combined with all attributes was non-trivial which seems to have ended
with little to no support and *no way to verify what support existed* in
individual products. So, what I’d like to see in this read only profile is a way
to provide a mechanism that limits Search using a combination of specific
operators and attributes. i.e. I will allow queries that allow only specific
operators combined with specific clauses. E.g. Allow only ‘and’
operations on attributes X, Y and Z. The two use cases that are expected to be enabled by this are: 1)
Ability to query the AP to retrieve attributes of multiple users
all in one shot, potentially for provisioning use cases 2)
Ability to do a one way synch from the AP to a local system..
i.e. The AP will always be the master system that will overwrite the local store The key here is to make sure that the profile itself is
constrained enough that it is implementable and testable. I am not sure if I answered your question to the level of detail
you are looking for but I am hoping that there is general interest in such a capability. Regards, -
Anil From: Gary Cole
[mailto:gary.cole@oracle.com] In what ways would you constrain search? Would these
constraints be minima, maxima or both? A provider constrains the set of object-classes for which
the provider supports search in the listTargetsResponse. Search as specified in SPMLv2 is at heart a subset of LDAP
search: - scope: 'pso', 'oneLevel' or 'subTree' - operators: 'and', 'or', and 'not' - clauses: dependent on profile or provider, but examples
show <attribute-name> = <attribute-value>. The DSML profile looks especially LDAP-like, since
DSML is basically LDAP wrapped in a bunch of XML tags. Nothing in the
specification of the base protocol nor the DSML profile requires a provider to
support fancier search than it wishes to provide. The provider simply
returns an error if: · The
provider cannot evaluate an instance of {QueryClauseType}
that the instance of {SearchQueryType}
contains. · The
open content of the instance of {SearchQueryType}
is too complex for the provider to evaluate. In short, it's entirely up to the provider how fancy to get
with search(). We figured that market-pressures would incent each
implementer to support search appropriately in its provider. For example,
SIM supported search on every type of object. OIM 9.x supports DSML
search for users. Gary On Mar 29, 2011, at 8:39 AM, John, Anil wrote:
Gary, Search gives you by default the equivalent of a batch
lookup.
We also need to re-read the specs to see if there is overlap
between
|
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]