RE: EntityId decision analysis page (wasRE:[higgins-dev]entityID notan a

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]

RE: EntityId decision analysis page (wasRE:[higgins-dev]entityID notan attribute?)

From: David Kuehr-McLaren <dkuehrmc@xxxxxxxxxx>
Date: Tue, 16 Sep 2008 17:15:10 -0400
Delivered-to: higgins-dev@xxxxxxxxxxx
List-archive: <https://dev.eclipse.org/mailman/private/higgins-dev>
List-help: <mailto:higgins-dev-request@eclipse.org?subject=help>
List-subscribe: <https://dev.eclipse.org/mailman/listinfo/higgins-dev>, <mailto:higgins-dev-request@eclipse.org?subject=subscribe>
List-unsubscribe: <https://dev.eclipse.org/mailman/listinfo/higgins-dev>, <mailto:higgins-dev-request@eclipse.org?subject=unsubscribe>

Responding to Jim's question

>> How does it help an application to know whether a context's entityIDs
>> are mutable?

An application may store IdAS identifiers in local stores so the objects can be retrieved later. There are use cases where an application will associate an EntityID to a non-Higgins database (e.g. customer order record, audit trail, work flow transaction, etc.). In these cases the application needs to know if the identifier represents the same person from one call to IdAS to the next. If the identifier is mutable, then the John Smith that starts a work flow may not be the same John Smith that ends a workflow.

Other issues occur when organizational changes or name changes affect a mutable EntityID. Again, applications that have stored the identifiers in application specific databases tend to break, when the identifier for a person changes.

David

David Kuehr-McLaren
Tivoli Security
919.224.1960

higgins-dev-bounces@xxxxxxxxxxx wrote on 09/16/2008 04:04:52 PM: > Yes, it's a good point Jim - all a getEntityIdsMutable method could do is > serve as an input to a application making policy decisions. > > More useful might be a method for asking an Entity specifically for an > immutable EntityId. Call it getCanonicalId. The rule would be that it always > returns one EntityId value that the Context asserts is the immutable > canonical identifier for that Entity in that Context. > > If the Context does not support immutable identifiers, then getCanonicalId > will return an error, and the application can plan accordingly. But I > suspect the value of having an immutable reference would incent CPs to > support this method. > > =Drummond > > > -----Original Message----- > > From: higgins-dev-bounces@xxxxxxxxxxx [mailto:higgins-dev- > > bounces@xxxxxxxxxxx] On Behalf Of Jim Sermersheim > > Sent: Monday, September 15, 2008 11:01 PM > > To: 'Higgins (Trust Framework) Project developer discussions' > > Subject: RE: EntityId decision analysis page (wasRE:[higgins-dev]entityID > > notan attribute?) > > > > How does it help an application to know whether a context's entityIDs > > are mutable? Does that tell the client that they'd better not use this > > Higgins policy objects (at least none that refer to entities as subjects > > or resources)? > > > > > > > > >>> "Drummond Reed" <drummond.reed@xxxxxxxxxxxx> 09/15/08 9:59 PM >>> > > Okay, after talking with Markus and Paul on the phone, and gathering the > > last round of comments in email, I did another update to > > http://wiki.eclipse.org/EntityId_Requirements. This should really be > > called > > "EntityId Requirements for Context Data Model 1.1", since what we're > > talking > > about here is the delta between what we have in 1.0 and 1.1. > > > > The current state as I understand it in 1.0 is that the entityId > > parameter > > to the getEntity method on IContext interface: > > > > 1. Is of type string (confirm?) > > 2. Has cardinality 0..1 > > 3. MUST be Context-unique; MAY be globally unique. > > 4. Is always exposed as an Attribute. > > 5. Exposes no information about mutability. > > > > Following are the proposed changes in 1.1. Please do comment on each > > one. > > > > #1: NOT REQUIRE entityId TO BE EXPOSED AS AN ATTRIBUTE > > > > The proposed change is to make EntityId OPTIONAL to expose as an > > Attribute. > > Contexts that do not want to expose the EntityId can omit it from the > > list > > of Attributes for an Entity. Note: if the EntityId is mutable, it SHOULD > > be > > exposed as an Attribute so it can be modified. > > > > #2: ADD getEntityIdsMutable METHOD > > > > The proposed change is to add a getEntityIdsMutable() method on IContext > > that returns a Boolean indicating whether EntityIds in that Context are > > mutable or not. True = mutable. > > > > #3: ADD getIdentifiers METHOD > > > > The proposed change is to add a getIdentifiers() method on IEntity that > > returns all Identifiers for an Entity (0..n). By definition this would > > return all identifiers that the Context considers to be synonyms of the > > EntityId, even if the EntityId was not among the values returned. > > > > #4: MULTI-PART KEYS > > > > The proposal is to keep it simple by requiring multi-part keys to be > > serialized into a composite identifier, which can then be used as an > > EntityId or exposed as an Identifiers attribute. > > > > Again, comments welcome so we can close this. > > > > =Drummond > > > > > -----Original Message----- > > > From: higgins-dev-bounces@xxxxxxxxxxx [mailto:higgins-dev- > > > bounces@xxxxxxxxxxx] On Behalf Of Tom Doman > > > Sent: Monday, September 15, 2008 1:34 PM > > > To: 'Higgins (Trust Framework) Project developer discussions' > > > Subject: RE: EntityId decision analysis > > page(wasRE:[higgins-dev]entityID > > > not an attribute?) > > > > > > +1 > > > > > > On #1, I think more complex could get CP implementors into some > > > difficult situations though that's just a hunch w/o concrete examples. > > > But, like Jim, I prefer simple. > > > > > > On "another question", I don't see how we could guarantee immutability > > > or referential integrity. I understand the need, just not how we'd > > pull > > > it off especially w/o producing a major house of cards to implement. > > > Event notification from the backing store, if even possible, would > > still > > > not be guaranteed to be reliable. Maybe doing the best we can is > > better > > > than no guarantee whatsoever. > > > > > > Tom > > > > > > > _______________________________________________ > > higgins-dev mailing list > > higgins-dev@xxxxxxxxxxx > > https://dev.eclipse.org/mailman/listinfo/higgins-dev > > > > > > ------------------- TEXT.htm follows ------------------- > > <html> > > <head> > > <style type=3D"text/css"> > >  > > </style> > > =20 > > </head> > > <body style=3D"margin-left: 4px; margin-bottom: 1px; margin-top: 4px; = > > margin-right: 4px"> > > > > How does it help an application to > > = > > know whether a context's entityIDs are mutable?  Does that = > > tell the client that they'd better not use this Higgins policy objects > > = > > (at least none that refer to entities as subjects or > > resources)&#63= > > ; > > =20 > > > > > > > > >>> "Drummond Reed" > > <drummond.reed@xxxxxxxxxxxx= > > > 09/15/08 9:59 PM >>> Okay, after talking with Markus > > = > > and Paul on the phone, and gathering the last round of comments in > > = > > email, I did another update to <a > > href=""> > > tityId_Requirements.">http://wiki.eclipse.org/EntityId_Requirements.</a>&n > > b= > > sp;This should really be called "EntityId Requirements for Context > > = > > Data Model 1.1", since what we're talking about here is = > > the delta between what we have in 1.0 and 1.1. The current state as > > = > > I understand it in 1.0 is that the entityId parameter to the getEntity > > = > > method on IContext interface:    1. Is of type = > > string (confirm?)    2. Has cardinality = > > 0..1    3. MUST be Context-unique; MAY be globally = > > unique.    4. Is always exposed as an > > Attribute. &#160= > > ;  5. Exposes no information about mutability. Following > > = > > are the proposed changes in 1.1. Please do comment on each > > one. &#35= > > ;1: NOT REQUIRE entityId TO BE EXPOSED AS AN ATTRIBUTE The proposed > > = > > change is to make EntityId OPTIONAL to expose as an Attribute. Contexts > > = > > that do not want to expose the EntityId can omit it from the list of = > > Attributes for an Entity. Note: if the EntityId is mutable, it SHOULD > > = > > be exposed as an Attribute so it can be modified. #2: ADD = > > getEntityIdsMutable METHOD The proposed change is to add a = > > getEntityIdsMutable() method on IContext that returns a Boolean > > = > > indicating whether EntityIds in that Context are mutable or not. True = > > = mutable. #3: ADD getIdentifiers METHOD The = > > proposed change is to add a getIdentifiers() method on IEntity = > > that returns all Identifiers for an Entity (0..n). By > > definition= > > this would return all identifiers that the Context considers to be = > > synonyms of the EntityId, even if the EntityId was not among the = > > values returned. #4: MULTI-PART KEYS The proposal is to > > = > > keep it simple by requiring multi-part keys to be serialized into a = > > composite identifier, which can then be used as an EntityId or = > > exposed as an Identifiers attribute. Again, comments welcome so > > = > > we can close this. =Drummond > -----Original = > > Message----- > From: higgins-dev-bounces@xxxxxxxxxxx > > [mailto:higg= > > ins-dev- > bounces@xxxxxxxxxxx] On Behalf Of Tom Doman > = > > Sent: Monday, September 15, 2008 1:34 PM > To: 'Higgins > > = > > (Trust Framework) Project developer discussions' > = > > Subject: RE: EntityId decision analysis page(wasRE:[higgins- > > dev&#93= > > ;entityID > not an attribute?) > > > > +1 >= > > > On #1, I think more complex could get CP implementors = > > into some > difficult situations though that's just a hunch w/o > > = > > concrete examples. > But, like Jim, I prefer > > simple. ><= > > br>> On "another question", I don't see how we could > > = > > guarantee immutability > or referential integrity.  I = > > understand the need, just not how we'd pull > it off = > > especially w/o producing a major house of cards to implement. > = > > Event notification from the backing store, if even possible, would > > = > > still > not be guaranteed to be reliable.  Maybe doing the > > = > > best we can is better > than no guarantee > > whatsoever. > >= > > > > Tom > _______________________________________________ higg > > = > > ins-dev mailing list higgins-dev@xxxxxxxxxxx <a > > href=""> > > clipse.org/mailman/listinfo/higgins">https://dev.eclipse.org/mailman/listi > > n= > > fo/higgins</a>-dev > > > > </body> > > </html> > > _______________________________________________ > > 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

References:
- RE: EntityId decision analysis page (wasRE:[higgins-dev]entityID notan attribute?)
  - From: Drummond Reed

Prev by Date: RE: EntityId decision analysis page (wasRE:[higgins-dev]entityID notan attribute?)
Next by Date: RE: EntityId decision analysis page (wasRE:[higgins-dev]entityIDnotan attribute?)
Previous by thread: RE: EntityId decision analysis page (wasRE:[higgins-dev]entityID notan attribute?)
Next by thread: RE: EntityId decision analysis page (wasRE:[higgins-dev]entityIDnotan attribute?)
Index(es):
- Date
- Thread

Breadcrumbs