[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [higgins-dev] IdAS Update Proposals


Jim,

I still think there is are good uses for applying a set of changes at the iContext level, but with the better understanding of how applyUpdate will work on IDigitalSubject, I think we can defer to the transaction discussion or a new discussion on batch operations.  Thanks.

David

David Kuehr-McLaren
Tivoli Security
919.224.1960



"Jim Sermersheim" <jimse@xxxxxxxxxx>
Sent by: higgins-dev-bounces@xxxxxxxxxxx

04/23/2007 08:26 PM

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

To
"Higgins (Trust Framework) Project developer discussions" <higgins-dev@xxxxxxxxxxx>
cc
Subject
Re: [higgins-dev] IdAS Update Proposals





David,
 
If we decide that applyUpdates is not required to be processed as an atomic operation, do you still see a compelling amount of utility in allowing that method at the IContext level?
 
Jim

>>> David Kuehr-McLaren <dkuehrmc@xxxxxxxxxx> 4/23/07 6:12 PM >>>

Jim, Tom,


I hope I am not being too difficult here.  I think that the ability for any applyUpdate operation on any of the interfaces to be atomic depends on the assumptions that are made about the capability of the context provider and the underlying native store.


Not all CPs could support that applying changes to multiple digital subjects. Whether the CP guarantees that all digital subjects and relationships will succeed (atomic) or it is possible for some updates to fail is a capability of the CP.  For example, the SAP UME supports batch multiple updates (SPML) where some of the updates could fail. Internally, I support a file based registry that will guarantee atomic updates to multiple subjects.  


I think the same issue may exist at the IDigitalSubject level with multiple attributes, unless I have missed an assumption (and I very well may have). A JNDI provider can assume it can support applyUpdates to a digital subject because JNDI operates at the DS boundary.  Is that assumed true for all providers? If there is a CP that is a virtualization of attributes from multiple sources (e.g. mashup), must this CP support an atomic applyUpdates? A CP for a repository that does not natively have a DS boundary will have the same implementation difficulties at the DS level as the JNDI provider will at the context level.    

David

David Kuehr-McLaren
Tivoli Security
919.224.1960



"Tom Doman" <TDoman@xxxxxxxxxx>
Sent by: higgins-dev-bounces@xxxxxxxxxxx

04/23/2007 06:02 PM

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


To
"Higgins (Trust Framework) Project developer discussions" <higgins-dev@xxxxxxxxxxx>
cc
Subject
Re: [higgins-dev] IdAS Update Proposals







Well I won't attempt to argue with myself ... :) ... especially since I wasn't really attempting to argue atomicity this time.  Rather, I'm just saying that if the semantics aren't specified as part of the API definition, that I could accomplish the task of "updating" differently than one might expect.  Hell, I think I was trying to agree w/ your question to David!  :)

>>> "Jim Sermersheim" <jimse@xxxxxxxxxx> 4/23/2007 3:54 PM >>>
But if it's atomic (which you argue should be the case in another message), then you could not implement it in the JNDI provider.

>>> "Tom Doman" <TDoman@xxxxxxxxxx> 4/23/07 2:41 PM >>>
Right, I could implement applyUpdates at the IContext level in the JNDI provider, of course, it'd have the transactional characteristics inherent in the JNDI APIs.

>>> "Jim Sermersheim" <jimse@xxxxxxxxxx> 4/23/2007 2:14 PM >>>
Ok, but what are the semantics of applyUpdates in this case?  Can the operation partially fail (some things get applied and others don't)?

>>> David Kuehr-McLaren <dkuehrmc@xxxxxxxxxx> 4/23/07 1:41 PM >>>

Jim,

I agree with Alex. In addition, having applyUpdates at the IContext level is a little different from supporting transactions. iContext applyUpdates allows the client application to submit a set of digital subjects and relationships that represent a valid state (e.g. create a person and add them to a set of groups), and/or allow the CP to efficiently support bulk operations.  Just like it is more efficient for an LDAP provider to submit all the attribute updates to a single digital subject at one time, other CPs that support backend with multiple subjects input can be more efficient if given a bag of digital subjects to update.

David

David Kuehr-McLaren
Tivoli Security
919.224.1960




Alexander Amies/Irvine/IBM@IBMUS
Sent by: higgins-dev-bounces@xxxxxxxxxxx
04/23/2007 12:12 PM
Please respond to
"Higgins \(Trust Framework\) Project developer discussions"        <higgins-dev@xxxxxxxxxxx>



To
"Higgins \(Trust Framework\) Project developer discussions" <higgins-dev@xxxxxxxxxxx> cc
"Higgins (Trust Framework) Project developer discussions" <higgins-dev@xxxxxxxxxxx>, higgins-dev-bounces@xxxxxxxxxxx Subject
Re: [higgins-dev] IdAS Update Proposals







Jim,

I don't see transaction support that is a problem particular to IdAS and the approach being proposed does not appear to be interoperable with other transaction service frameworks.  A better approach
than building transactions into IdAS may be to rely on other transaction frameworks, such as JTS / JTA implementations.  These can be used from within the Spring Framework in a totally transparent and container independent way.

Alex




"Jim Sermersheim" <jimse@xxxxxxxxxx>
Sent by: higgins-dev-bounces@xxxxxxxxxxx
04/20/2007 07:51 AM

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


To
"Higgins (Trust Framework) Project developer discussions" <higgins-dev@xxxxxxxxxxx>cc
Subject
Re: [higgins-dev] IdAS Update Proposals








David,

In an earlier proposal, I had placed it at the IContext level and we ended up spawning a transactions subthread which was sort of derailing progress on the update operations issue.  Once people see transaction semantics across Digital Subjects, they then want them across Contexts.  So I was hoping we could table that, address the minimum need for updates, and talk about actual transactions in another thread.

Mike and later others have suggested we think about introducing an ITransaction interface.  You could get an instance of this and pass it to methods which you want to be part of the transaction.
Jim

>>> David Kuehr-McLaren <dkuehrmc@xxxxxxxxxx> 4/19/07 8:52 PM >>>

Jim,

Sorry to jump into this thread so late in the game. I work for IBM and I support various user repositories that need to be accessed and managed via IdAS. I have some comments and questions about the applyUpdates from the distillation page (a very nice summary, BTW).

Under "Placement of the applyUpdates method", I like the simplicity of bullet 1 (applyUpdate only on IDigitalSubject), but I also have the need to be able to update multiple IDigitalSubjects as an atomic operation. One use case for this is the ability to create a person and add them to a group as a single operation. Would applyUpdate on IContext allow atomic operations involving multiple IDigitalSubjects?  

David

David Kuehr-McLaren
Tivoli Security
919.224.1960


"Jim Sermersheim" <jimse@xxxxxxxxxx>
Sent by: higgins-dev-bounces@xxxxxxxxxxx
04/19/2007 02:20 AM

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



To
<higgins-dev@xxxxxxxxxxx>cc
Subject
Re: [higgins-dev] IdAS Update Proposals










BTW, I was referring to this page ( http://wiki.eclipse.org/index.php/IdAS_Update_Proposals_Distillation )

>>> "Jim Sermersheim" <jimse@xxxxxxxxxx> 4/18/07 11:47 PM >>>
I've added some method declarations and copious amounts of javadoc-style comments to try to paint a picture of how each would be used. If I have time tomorrow, I'll add pseudo use-case code.

A note about the remove() methods; You'll see that I put these at the element to be removed.  I had to pick one way or the other, so I picked this.  We can explore putting remove(identifiedThing) at the container lever if people dislike this.

Jim

>>> "Jim Sermersheim" <jimse@xxxxxxxxxx> 4/18/07 6:40 PM >>>
The way I envision most of the proposals which have mod methods on each element working is such that the CP will always know the relationship between the element and its enclosing element.  For the LDAP provider, I think the tracking of updates will just be a matter of implementing the mod methods by pushing the mod onto a stack of mods, and then calling ldapmodify when the user calls applyUpdates.

I think it will be more clear when I add the method decls, and flesh out a few use cases.  For now, the family is scowling and wants to go to the pool.

Jim

>>> "Tom Doman" <TDoman@xxxxxxxxxx> 4/18/07 4:43 PM >>>
Tracking of updates by the CP has been one of my biggest concerns throughout the creation of these alternative proposals.  I'm trying to work out in mind how each proposal effects the complexity of that task for every CP that will not immediately update on every add, remove, or modify.  I should add that I expect the majority of CPs to fall into this category.  Anyway, I'm just considering tracking each update, putting any transactional considerations aside.

I've just re-reviewed each of the alternate update proposals and here's how this issue breaks down:
1. No tracking of updates.  I'm still not convinced that the current list of Cons makes this completely untenable.  Maybe it's missing some.
2. No tracking of updates since everything isn't immediately committed to the backing store.  We actually couldn't do this anyway with an LDAP backing store, even if we decided to ignore the wretched performance footprint that would result.

Everything else includes tracking of updates and some method of allowing both IdAS consumer and CP implementor to know when it's time to apply the changes.  Do any of the proposals or modifications thereof (under 3 & 4) materially change the complexity of the tracking task.  My big fear here is that we are going to place such a large burden on most CP implementors and give each one a house of cards to contend with.  Perhaps some of the proposed methods do make this more manageable but as I read through the distillation proposal, I looked at the bookkeeping involved and I'm worried.

If each IdAS element has add, remove, and modify methods and each element includes an applyUpdates method, then each element has to know who it's enclosing element is so that any applyUpdates can cascade down.  As I modify a value of an attribute, I need that knowledge to cascade up to the Context level so that it knows there's an update to apply unless we place it only on IDigitalSubject.  However the same basic situation persists, every level knows about it's encloser and the highest level enclosure must be notified.

This has gotten me thinking about some sort of change cache and notification interface instead or something that makes change tracking cleaner and more manageable.  Jim's not here to bounce this stuff off but I'll see if I can come up with something to address this concern.

Tom

>>> "Jim Sermersheim" <jimse@xxxxxxxxxx> 4/17/2007 10:01 PM >>>
I was going to add a 3.b or something like that but started a number 4 ( http://wiki.eclipse.org/index.php/IdAS_Update_Proposals_Distillation) instead (I also changed the main proposals page ( http://wiki.eclipse.org/index.php/IdAS_Update_Proposals) by moving each option to its own page).

Option 4 ( http://wiki.eclipse.org/index.php/IdAS_Update_Proposals_Distillation) is my attempt at distilling and simplifying the existing options along with feedback from the list.  I still need to add the method declarations, but we need consensus on a few things.

I simplified it by breaking it into two required parts (how we specify an update, how and where we specify the application of an update to the backing store)

Then there's a section for optional stuff that we need to agree on (or agree to leave out for now).

Valery, I've probably mis-represented your intent from http://dev.eclipse.org/mhonarc/lists/higgins-dev/msg02224.html.

Jim

_______________________________________________
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
_______________________________________________
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

_______________________________________________
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

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