[Igf-dev] [higgins-dev] IdAS API extensibility

[Phil Hunt]

Jim,

Just to capture our offline discussion, we talked about a couple of  
alternatives:
--------------
On one hand, there are the java interfaces, which we try our best to  
keep very abstract, so that any consuming application's code can be  
provider agnostic.

Then there is the context provider-specific configuration which goes  
quite far in the other direction.  When dealing with that, the  
consumer has to have pretty intimate knowledge of the provider.
--------------

I think maybe the best way is to go with Java interfaces for any  
functionality that should be available (or at least possible) across  
*any* provider. This makes the new functionality clearly documented  
and well exposed. It also allows the client code to test if the  
functionality is implemented by checking the interface. Over time,  
should an interface become "typical", it might be reasonable to  
deprecate older method signatures over time.

If however an extension or feature is specific to one provider (or 2)  
but does *not* make sense for all providers, then context provider- 
specific configuration would be the way to go. The client developer  
need not be aware of the feature, but at least the deployer could  
configure the feature.

In the case of IGF, implementation is meant to be supported across  
all providers, but each provider will be implementing policy  
differently. This suggests the need for IGF to have an interface as  
the implementation issues *need* to be abstracted from the client.

Also, note that in the case of IGF, the client is intentionally aware  
of IGF and needs to know whether the provider is fully capable. One  
of the benefits of being aware of IGF is that the client code can  
actually be more abstracted from protocol and deployment issues. To  
the developer, CARML is simply the application's schema (plus rights  
metadata). But to the deployer, it tells how to configure the  
services infrastructure to best meet the needs of the app. The  
"layers" of Higgins can then figure out how to map CARML requirements  
to data available from various context providers or federated sources  
(e.g. STS). The layers can then route to appropriate providers and  
configure protocol policies (e.g. WS-SecurityPolicy).

I propose creating a generic interface for policy extensions which  
would allow for multiple policy implementations like IGF & EPAL.  For  
example, hypothetically, IContextIGF and IContextEPAL could be   
subclasses of IContextPolicy which subclasses IContext. A provider  
supporting both interfaces, could tell the type of interface being  
used by either method signature or by the type of Policy object that  
was passed in.

Finally, I think we've also talked about callouts or callbacks. I  
have a feeling this won't work unless the requirement just involves  
manipulating the data as it transits the IdAS interface. In the case  
of IGF and JNDI, we're likely talking about converting policy and  
encapsulating it in an LDAPControl. In the case of OpenID, it would  
be mapping policy to http fields. Etc.  It may be doable as a call- 
out, but it may actually change how the basic call to the protocol is  
made. I suspect, we'll have to take it on a case by case basis.

Phil Hunt
Oracle


On 5-Dec-07, at 8:46 AM, Tom Doman wrote:

> Jim,
>
> Actually, I think you're right.  You'll probably have to implement  
> your best guess and let those who require it, drive changes.  Right  
> now, Phil has the best use case, correct?  I'd say, start there and  
> go for it!
>
> Tom
>
>>>> "Jim Sermersheim" <jimse at novell.com> 12/04/07 8:26 PM >>>
> If history is an indicator of how to get input on a topic like  
> this, I should implement this in an obviously wrong way and then  
> wait until someone tries to code to it.
>
> Anyone have any input?
>
>
>>>> "Jim Sermersheim" <jimse at novell.com> 11/30/07 6:48 PM >>>
>
> I need to know how to best address https://bugs.eclipse.org/bugs/ 
> show_bug.cgi?id=196390 ( https://bugs.eclipse.org/bugs/show_bug.cgi? 
> id=196390 )
>
>
> I put out a wiki page at http://wiki.eclipse.org/ 
> IdAS_API_Extensibility.  This describes some of the proposed ways  
> of making APIs extensible.
>
>
> If you're a context provider writer, or a consumer of IdAS (or just  
> interested at all), could you please look at this wiki and give  
> feedback.  Feel free to add more proposals, or pros or cons to the  
> page, or talk about them here.  I tend to favor #4 ( http:// 
> wiki.eclipse.org/IdAS_API_Extensibility#extendedOperation_method )  
> and #1 ( http://wiki.eclipse.org/ 
> IdAS_API_Extensibility#Add_just_one_more_argument ) right now.
>
>
>
>
> _______________________________________________
> higgins-dev mailing list
> higgins-dev at eclipse.org
> https://dev.eclipse.org/mailman/listinfo/higgins-dev