[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [higgins-dev] IdAS: The contract CP's must followforincomingobjects
- From: "Tom Doman" <TDoman@xxxxxxxxxx>
- Date: Fri, 06 Apr 2007 10:50:15 -0600
- Delivered-to: email@example.com
There are two possible approaches I see, each with their own drawbacks:
1. Work around chicken and egg problems such as the AuthN materials issue with alternate contracts and maintain the build* methods.
This approach would not be confusing to the consumer and the benefits of allowing each CP to create it's own kind of attributes remains it tact. However, it means a new interface in the case of the AuthN materials and doesn't mean we won't find some other chicken and egg problem which will require yet another alternate interface. If we move to a JAAS style authN in the future, that chicken and egg problem may not even exist and we may then have no other reason to have removed the build* methods and their potential benefits in the first place.
2. Make the interface the contract.
This approach is would also not be confusing to the consumer but removes the potential benefit of allowing each CP to create it's own kind of attributes. I anticipate performance being an issue as Higgins components are used in enterprise environments and also that allowing CPs this control will help improve performance. That may be a bad assumption but if we don't allow at least the existence of the build* methods, CP implementors will not have the option to do special maneuvers based on knowledge only they can have.
2.a. Make the interface the contract but still maintain the build* methods.
This approach is confusing to the consumer because he\she sees examples where attributes are newed and examples where they are built. The consumer then has to read some documentation which prescribes the appropriate use of new and build.
So, I guess I favor, 1, 2a, then 2. I like 1 for now most because we don't even know if that particular example will even be a problem in the future and I'd hate to switch to 2 and find out we didn't have to do it that way.
>>> "Jim Sermersheim" <jimse@xxxxxxxxxx> 4/6/2007 10:04 AM >>>
What you're talking about has to do with keeping the build* methods around, even if we decide to allow consumers to instantiate and pass any instance (whether Basic* or otherwise). I was reserving that as a follow-up question if it looked like people preferred making the interfaces be the CP's contract, but we can talk about that as well.
In the event that we decide to make CP's allow any IAttribute, IPropertyValue, etc. to be passed into update and search methods, we can either keep the build* methods around and make some statement like "when possible, it may be best for IdAS consumers to create instances of the <x, y, and z> interfaces by calling the build* methods. This allows the context provider to possibly return specialized instances which may bring certain performance and scalability benefits". The drawback is that it may be confusing. To the lax reader, it won't be obvious why some code calls build* while other code calls new <whatever>. So if you have an opinion about the first point, you may as well chime in on this at the same time.
I assume Tom, you favor CP's following interface contracts (rather than only allowing instances of their own making), and retaining the build* methods.
>>> "Tom Doman" <TDoman@xxxxxxxxxx> 4/6/07 9:35 AM >>>
Does it have to be either\or? What about the blend we discussed? Namely, having CPs support their own when passed (for efficiency, performance, etc. sake) and the standard interface and "brute force" approach when it's not. Would that be too complicated? I hate the thought of choosing the interface only method simply due to AuthN materials issues. I'd almost rather change AuthN materials to be a special vector or something.
>>> "Jim Sermersheim" <jimse@xxxxxxxxxx> 4/6/2007 8:07 AM >>>
We have a number of IdAS methods that take as input some interface or another. For example, IContext.addSubject takes a set of IAttribute instances, IContext.getSubjects takes an IFilter instance.
So, how does an IdAS consumer get an object to pass to one of these methods? To date, we've said that they have to get them from the context provider -- this is why we have IContext.build* methods (IContext.buildAttribute for example will build an IAttribute instance which could then be passed to IContext.addSubject. On thee other hand, there are Basic implementations (like BasicAttribute) that are easy to instantiate without the help of a context instance.
We need to decide whether the IdAS consumer must call the build* methods to get interface instances to be used as arguments to subsequent method calls, or whether the contract is simply the interface -- in other words, the CPs must allow any object to be passed as long as the object implements the prescribed interface.
Arguments for making the IdAS consumer to always call build methods to create interface instances:
- CP controls all instances. This allows the CP to always deal with its own well-known concrete classes. It may be able to do things that increase performance and scalability. It also allows the CP to cause a failure earlier when the consumer is requesting something that doesn't fit the context's model (schema).
Arguments for making the CP allow any instance of an interface to be passed:
- Consumers can new an org.eclipse.higgins.idas.impl.Basic* class without having an IContext instance and later use it (and re-use it).
- Seems like a more natural programming model.
- Solves a chicken and egg problem which is this:
Some org.eclipse.higgins.idas.impl.AuthN* classes work by populating themselves with properties (like name and password). Today, these are simply instantiating BasicProperty objects which hold BasicValueString data. This is wrong according to the existing model. To keep with the existing model, I must change these such that the constructors require an IContext instance so I can call IContext.build* to create these properties.
That change means two things to the consumer: 1) The consumer must already have an IContext instance. 2) The consumer cannot re-use an AuthN*Materials across contexts. It means something worse to the CP. Some CP's will require that open is called prior to allowing build* methods to be called. If we need to get an AuthNNamePasswordMaterials to open the context, but we can't until the context is open, then we're stuck.
So, do people think a CP should allow any instance of a prescribed interface to be passed as an argument, or do we want to maintain that only instances produced by that CP's build methods may be passed?
higgins-dev mailing list