Re: [higgins-dev] [IdAS] use cases

[Greg Byrd <gbyrd@xxxxxxxx>]

Some comments before I describe a strawman design.

First, I realize that the use cases are context-centric.  In other 
words, the view is that the user cares only about the Context as data, 
not its underlying representation.  (The "import" case is the exception.)

Second, to address one of Tom's questions, I do think that it's possible 
for different Context Providers to source the same Context URI.  In one 
such case, the data source is a well-known public LDAP directory -- 
different Context Providers are essentially Higgins interfaces which 
point  to that common information.  In another case, the same data 
could, in fact, be represented in different raw formats.  I don't know 
how useful this is, but consider if the URI represents "Raleigh 
residents."  If the City of Raleigh publishes that information as a flat 
file, I could import that information into an SQL database.  In both 
cases, Context Providers could legitimately claim to represent that 
URI.  (Again, this might not be a good example -- once an independent 
copy of the info exists, shouldn't it have a different URI?)

----------
STRAWMAN DESIGN

ContextProvider extends java.security.Provider
-- registered via java.security.properties file, or via Security.addProvider

ContextFactory is a service type (abstract class), and its only legal 
algorithm is "higgins".
-- propose "higgins" as algorithm, so that a single factory can support 
multiple underlying data storage formats
-- an attribute "DataTypes" specifies a list of all underlying data 
formats supported by this factory
-- does most of what we used to call ContextProvider (open, close, 
metadata, policy...)

Context is a service type (abstract class), and its algorithm string is 
its URI
-- an attribute "FactoryClass" specifies the class name of the 
ContextFactory that creates this type of context
-- static method getInstance(URI) to create a Context object via a 
particular provider and factory
-- Question: Is a provider allows to have several services with the same 
algorithm, but different attributes?

-----------
USE CASE 1 -- User has URI of a Context and withes to open it.  No 
constraints on provider.

1. User calls Context.getInstance(<uri>).
   2. Context.getInstance() calls 
Security.getProviders("Context.<uri>").  This returns an array of 
Providers in preference order.
   3. Calls provider.getService("Context.<uri>") using the first 
Provider in the array.
   4. Calls service.getAttribute("FactoryClass").
   5. Creates an instance of the factory class.
   6. Calls factory.openContext(<uri>).
   7. Returns Context.


USE CASE 2 -- User has URI of a Context and wishes to open it using a 
specific provider.
1. User calls Context.getInstance(<uri>, <provider>).
   2. Context.getInstance() calls Security.getProvider(<provider>).
   3. Calls provider.getService("Context.<uri>").
   4. Calls service.getAttribute("FactoryClass").
   5. Creates an instance of the factory class.
   6. Calls factory.openContext(<uri>).
   7. Returns Context.

USE CASE 3 -- User wishes to determine which providers are available for 
a particular Context.
1. User calls Security.getProviders("Context.<uri>").  Returns a 
preference-ordered array of Providers.

USE CASE 4 -- User wishes to import a Context that is already 
represented in a specific format.
(NOTE: What this means is that the user needs to locate a ContextFactory 
that supports the proper type, then somehow initialize
a Context using the imported information.  The details of this may not 
be quite right, but I'm trying to capture a case when
the user needs a particular underlying technology.)
1. User calls Security.getProviders("ContextFactory.higgins").  Returns 
an array of Providers in preference order.
2. For each Provider in array, call 
provider.getServices("ContextFactory.higgins").  Returns a set of 
Provider.Service objects.
3. For each service object, do service.getAttribute("DataFormat").
4. Search attribute string for the format (e.g., "LDAP").
5. If match, call service.getInstance() to get a ContextFactory and then 
do whatever's needed to initialize the Context.


USE CASE 5 -- User wishes to find out which Contexts are available using 
the currently-installed providers.
1. User calls Security.getProviders().
2. For each provider, calls provider.getServices().
3. Search for type = "Context" in service set.  If non-null, add to 
return list.