Re: [higgins-dev] IDAS context provider and endpoint APIs

[Nataraj Nagaratnam <natarajn@xxxxxxxxxx>]

Some comments like <raj>
this </raj>

Greg Byrd <gbyrd@xxxxxxxx>
Sent by: higgins-dev-bounces@xxxxxxxxxxx

07/12/2006 11:12 AM

Please respond to
"Higgins (Trust Framework) Project developer discussions" <higgins-dev@xxxxxxxxxxx>

To	higgins-dev@xxxxxxxxxxx
cc
Subject	[higgins-dev] IDAS context provider and endpoint APIs

I'm starting an implementation of the framework class (IdASEndpoint), 
and I have the following suggestions/questions:

(1) IContextProvider needs a getIdentifier method.  We will want to
list 
registered providers in a human-readable way.
<raj> Would getName()
be sufficient? Or would that identifier be used for any other purpose (e.g.,
metadata, policy, etc)... wondering about use case for getIdentifier (for
that matter.. getUniqueIdentifier()). </raj>

(2)  In order to implement the IIdASEndpoint getContextMetadata method,
there needs to be a way to connect a context URI with a provider. 
<raj> hmm... interesting
implication or assumption here. Does all of ContextMetadata depend on ContextProvider?
Is there is no metadata that can be used independent of a provider? </raj>
 We can either define a specific format for the
ContextRef that does this, 
or we can rely on the context registration process to map contexts to 
providers.  (I think that providers should explicitly register the
contexts that they want to be publicly accessible via the endpoint.)  If
the latter, we need to change registerContext(URI) to 
registerContext(URI, provider).
<raj> yea..
if contexts cannot exist without a provider (which is true to access the
info), then you are right.

 Is Context to Provider
a one to one mapping or would IdAS framework be capable of aggregating
providers for a given context?This is related to the discussions we had
at the F2F.  I thought the initial 'implementation' related design
agreement was that we will keep it simple wrt providers to do aggregation.
But i think IdAS impl needs to provide the support for aggregating, federating,..providers
based on context requests. ofcourse.. above updated api can be used (called
more than once) to associate multiple providers for the same contextref/uri.</raj>


(3) To support (2), do we want an "initialize" method for 
IContextProvider, or some sort of "registerContexts"?  We
need to 
somehow pass the endpoint object to the provider, so that it can perform
the registration.
<raj> 
Depends on if  the provider
need to self-register? 

Let me think thru this..


(a) I think provider's registration
to Contexts cannot be in initialize(). As providers can be initialized
and reused across multiple contexts. 

(b) If we have, registerToContext
like method on providers, question is .. who is going to invoke it? IdASEndPoint
or someone else? 
There are atleast two use
cases i can think of
    (i) IdASEndpoint
based on its configuration.. registers the provider. In which case, method
in #2 above (registryContext) on the IdASEndpoint would take care of it.
    (ii) Someone
else.. (outside of IdASEndpoint), would register a provider and bind it
to a particular Context, in a particular IdASEndpoint. In that case, instead
of asking the provider to self register, it can as well ask the IdASEndpoint
to register that provider. 
would that work?
</raj>

(4) We need IContextProvider to have a getContextMetadata(URI) method,
because we can't convert a URI to an IContext without opening the 
context -- <raj>yep.
btw.. wrt terminology, you
dont need to 'open' a context to get 'metadata', right? Metadata should
be accessible without 'opening' it. When I say 'open', I am referring to
the discussions about things like 'ldap bind' operation. The method may
still be required .. but I am trying to differentiate between instantiating
a context (so that it can be opened), vs opening a context. </raj>
so the endpoint can't call getMetadata on an IContext
because 
it doesn't have one.  (Alternatively, we need another way to create
an 
IContext object, and we rely on state information to know whether it's
open or not.) 

(5) Relevant to (4), I'd like to change all of the context-related 
methods in IIdASEndpoint to use URIs instead of context objects.

...Greg


_______________________________________________
higgins-dev mailing list
higgins-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/higgins-dev