[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [higgins-dev] [IdAS] use cases
|
Caveat: I'm still rather new to this, also, so take the following
explanations with
a grain of salt, and correct me as needed.
Tom Doman wrote:
1. I guess I had thought of Context Providers as being providers of a
specific kind of context. For example, an LDAP Context Provider that
provides Contexts to LDAP endpoints or a Join Context Provider that
provides Contexts to other Context Providers which, say, join data from
LDAP, SQL, and Liberty endpoints. How far off the mark am I here? Some
of what was discussed on the call as well as these use cases seem to
indicate that any given Context Provider can provide a Context to the
same URI. And perhaps the Context Providers then are just different
vendor implementations of how to get a Context for a given URI. I'm
sure much of my thinking is guided by what we've implemented in Bandit
and I'll send the promised examples under separate cover. I went
through the Java Docs yesterday but I'm still unclear on exactly what
Context Provider and Context are. In addition, as per #2 below, how
they can be used to encapsulate or join a variety of disparate data
sources and data formats.
"Does a Context Provider specify a type or a vendor?" I think the answer
is, "Both."
A Context is a technology-neutral concept. It contains a set of digital
subjects, and the
things that it can represent are described by its schema. But at the
Context level,
nobody cares whether the underlying bits are in an LDAP directory, or a
text file,
or an SQL database. It's the ContextProvider's responsibility to
translate the bits
in the repository to the form that can be used as a Context.
So, the Context Provider certainly needs to know what the storage technology
is and how to use it. It could also source data from many different
formats, presenting
the results as a unified Context with a specific schema.
But the Context Provider also represents a specific vendor's (or author's)
code to implement that transformation. So it's possible to have a
Novell-LDAP
provider and an IBM-LDAP provider.
I think I muddied the waters with my explanation of the Provider class
as used
in the Java Crypography Architecture. In that case, a Provider
represents a particular
implementation of some set of JCA services, which might be digital
signature,
encryption, message digest, etc. A Provider can implement any or all of
these
services. So I was thinking that the "IBM" Provider, for example, would
include
many different types of Context Providers that we've been talking about,
each with
different underlying technologies -- LDAP, RDF, SQL, or some custom
combination
of these.
Now, if I follow Tony's logic correctly, I think we're back to equating
Provider
(in the Java sense) with Context Provider (in the Higgins sense). In
other words,
each Provider has a specific way that it provides access to Context
data. And if
there is a need for different kinds of tranformations, because of
different underlying
technologies, then a vendor may have several different Providers, each
serving
a particular need. An attribute could be associated with the Provider
that tells
which underlying technology (or technologies) it supports.
2. Use case number 4 makes me wonder what it means to "import a
Context" but I assume that'll become clearer in Greg's description. It
does, however, raise an additional use case I'd like to see added and
detailed. That is, the case where the user wants a Context which
gathers identity data for a variety of data sources, each of which may
have data represented in a distinct specific format (e.g. LDAP, SQL, XML
File, etc.).
What I mean by "import" is the following. Suppose that my company has a
pre-existing
LDAP directory with information about all my employees. I want to make
that information
available to the Higgins framework. I don't want to implement my own
LDAP-based Context
Provider. Instead, I look at the Providers available on my system,
check whether any of them
supports an LDAP backend, and then I do whatever configuration is
necessary to make my
data available as a Context (or a set of Contexts) via that Provider.
3. A clarification on what end points are would also be helpful.
My understanding of IdASEndpoint is that it's the "place" where a user
goes to initiate
interaction with one or more Context Providers. It's the top-level
interface to the IdAS.
Jim has pointed out that "endpoint" might not be the best name for this,
and I don't
disagree.
