I'm gonna carve some of this stuff down into more focused questions,
then I can ask them one at a time, as they come.
I'm still having some heartburn on understanding vendor specific
Context Providers. If IBM has created a perfectly good LDAP Context
Provider, why would I want to write one at Novell? Wouldn't I rather
use IBM's and contribute enhancements and bug fixes to it? Or, in
Higgins, are we simply focusing on having an open source framework where
the Context Providers may be closed source? If they're planned to be
closed, I get it, acid reduced. ;) However, I would certainly like to
see encouragement for common Context implementations be part of the
Higgins goals.
Thanks,
Tom
Greg Byrd <gbyrd@xxxxxxxx> 7/20/2006 1:48 PM >>>
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.
_______________________________________________
higgins-dev mailing list
higgins-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/higgins-dev
_______________________________________________
higgins-dev mailing list
higgins-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/higgins-dev
