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