|
Phil,
I think I captured a new proposal out of this at http://wiki.eclipse.org/IdAS_API_Extensibility#Traditional_OO_extensions along with the advantages and drawbacks I see with it. I'll get a little more input tomorrow toward what people prefer.
You had also mentioned that we need to consider how one goes about extending an existing context provider such that it can handle new extensions. I think this defines a new IdAS player. Today we have an IdAS consumer, IdAS CP writer, and IdAS CP Deployer. We could say there is also an IdAS CP extender. Depending on the nature of the extension and its relationship with the underlying CP implementation, this person may or may not need to have intimate knowledge of the CP being extended.
I *think* we can separate this issue from the one presented at http://wiki.eclipse.org/IdAS_API_Extensibility but at the least, it's good to think about while weighing the options there. Anyway, I put a section called "CP extender impact" on each proposal so we can at least keep track of ideas.
Jim
>>> Phil Hunt <phil.hunt@xxxxxxxxxx> 12/05/07 11:54 AM >>>
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
_______________________________________________
higgins-dev mailing list
higgins-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/higgins-dev
|
