[higgins-dev] Vendor Specific Context Providers

["Tom Doman" <TDoman@xxxxxxxxxx>]

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