[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [higgins-dev] IdAS API extensibility
|
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@xxxxxxxxxx> 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@xxxxxxxxxx> 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@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/higgins-dev
