Re: [higgins-dev] What happened to createSubject()?

[Alexander Amies <aamies@xxxxxxxxxx>]

Jim,

That is what I am looking for.  For
the ansynchronous case, I agree that it could be an entirely separate topic.
 Actually, a smart (ie more difficult to implement) ansynchronous
provider could pretend that it is a synchronous provider by combining the
identity registry with any pending addSubject() requests.

Alex

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

03/28/2007 12:19 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] What happened to createSubject()?

Alex,
 
For the first case, the user does this:
 
String newID = myContext.addSubject(<subjectType>,
<attributes>, <metadata>);
 
The context implementation figures out what the cuid should
be (likely based on the attributes passed in) and returns that cuid as
the return argument.  I think this is exactly what you're asking for
below.
 
In regards to the second case, all IdAS methods are synchronous
right now.  When execution returns from addSubject, then that means
the subject has been added.  If this requires a long period of time,
it will take a long time for execution to return.  If we need to add
asynchronous methods, I think we need to open up an entirely separate topic
for that.
 
Jim

>>> Alexander Amies <aamies@xxxxxxxxxx> 3/28/07 11:42 AM
>>>

Jim, 

Two cases that are difficult here are (1) when the user requesting the
account doesn't know what the cuid is and (2) when the request is asynchronous.
  

For the first example, in many cases the cuid is an organization's policy
not the user's choice.  It may be an employee number of a set convention
based on surname and initials.  As an example, I would not be allowed
to choose the cuid 'root' or 'Administrator' if I was to request an account
on a UNIX or Windows system.  So then we submit an addSubject request
with no cuid (say null), then the impementation figures out what it should
be, and then tells the user.  This is going to be difficult or impossible
with the present interface. 

For the second use case, suppose that you submit a request to create an
account for some time in the future or subject to a human doing some work.
 This is very common for employee or contractor accounts when the
employee does not start until some point in the future or some kind of
approval is needed.  If you call back after the addSubject() call
then the user may not have been added to the registry.  The user may
be somewhere in a schedule table or a workflow system and it may be difficult
to retrieve the information from there.  Suppose that you have a contractor
with a contract expiration period and you want to suspend or delete the
account at the end of the contact period.  If you don't have a IDigitalSubject
after immediately after adding the account then you have to wait until
they appear in the registry.   

Alex

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

03/27/2007 04:00 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] What happened to createSubject()?

The least common denominator use-case is that callers of IContext.addSubject
do not need a full-blown IDigitalSubject instance to be returned.  So,
the thought was that when an IDigitalSubject was needed, one could call
IContext.getSubject using the returned cuid, like: 
  
IDigitalSubject myNewSubject = myContext.getSubject(myContext.addSubject(<args>),
<null, or attr list>); 
  
Are there cases that can't be met by the above? 
  
If we want IContext.addSubject to return an IDigitalSubject instance, we
would also want to allow an attrSelectionList argument (see IContext.getSubject)
to also be passed.  It seemed a bit much during the refactoring. 
  
Jim 
  


>>> Alexander Amies <aamies@xxxxxxxxxx> 3/27/07 3:47 PM
>>>

I noticed in last night's build there is no createSubject() method on IContext.
 Sorry if this has been discussed before but there is no search on
the mail archive to check (any plans on adding this?).

I think that it was a good move to only have either an addSubject or a
createSubject() but the createSubject() returned a IDigitalSubject, which
will be important in a few use cases. 

(1) In UNIX and a number of other user registries a user account is normally
created with a user name and a few other optional attributes.  The
UNIX ui is created automatically by the system.  I thought that the
return IDigitalSubject on createSubject() was a good way to pass this back.
 There may be other attributes automatically created, such as home
directory, email address, etc. 
(2) In asynchonous account creation it may be useful to pass back the IDigitalSubject
with the requested attributes and a pending status.

Alex 

***********************************************************************
Alex Amies
aamies@xxxxxxxxxx
Tivoli Identity Manager
http://www-306.ibm.com/software/tivoli/products/identity-mgr/
714 438 5085
***********************************************************************

"Sergey Lyakhov" <slyakhov@xxxxxxxxxxxxxx>
Sent by: higgins-dev-bounces@xxxxxxxxxxx

03/27/2007 09: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	Vadim Synakh <synakh@xxxxxxxxxxxxxx>, "'Igor Tsinman'" <igor@xxxxxxxxxxxxx>, Paul Trevithick <paul@xxxxxxxxxxxxx>
Subject	Re: [higgins-dev] IdAS is now Java 1.4

Jim, 
 
> - If the IdAS consumer got the IProperty instance from IContext.buildAttribute,
and then called setValue, we can assume it > sets the value only on
the in-memory IProperty instance (I think) 
 
Yes, in my opinion, buildSimpleValue, buildComlexValue and buildAttribute
methods should always create only "in-memory" objects. 
 
 
> Let's assume there was a setValue method on IProperty.  What
are the exact semantics of it? 
> - If the IProperty instance was gotten by the IdAS consumer by calling
IDigitalSubject.getAttribute, would setValue cause > that value to be
updated on the underlying data at that point in time?
 
> - If the IdAS consumer got an IProperty instance from IContext.buildAttribute,
then used that IProperty instance to call 
> IContext.addSubject, and after that called setValue on the IProperty
instance, does that update the value on the new 
> subject in the context? 
 
Because IContext doesn't support transactions, I think this operation (IProperty.setValue)
should immediately update the value if Subject was already "added"
to the Context (in terms of previous IdAS model where were two methods
 createSubject(....,  boolean add) and addSubject(IDigitalSubject
subject)). If subject is not yet added to the context it is "in-memory"
object and all operations with such Subject are also "in-memory".
 
As I understand, updateSubject(String
cuid, Iterator updates) method was added to IContext interface to provide
some data integrity support. However it doesn't work if we need to update
more then one Subject per one "transaction". In
my opinion the best decision was to add to IContext some methods like commitChanges()
and discardChanges(). So, objects like UpdateOperation should be generated
implicitly by calling methods like setValue(), createSubject(), addAttribute()
etc. if the context is based on some technology which doesn't support transactions
directly. 
 
 
> - If the IdAS consumer uses the same IProperty instance when creating
two Digital Subjects (via IContext.addSubject), 
> and then calls setValue on that IProperty instance, does it update
both Digital Subjects? 
 
> - If the IProperty instance was gotten by the IdAS consumer by calling
IDigitalSubject.getAttribute, and then used that 
> IProperty instance to create a new Digital Subject, would setValue
update both Digital Subjects? 
 
> If we allow IProperty instances to be used to update the Digital Subjects
to which they are associated, it means Context 
> Providers will need to maintain associations between IProperty instances
and the Digital Subject(s) to which the IdAS 
> consumer has associated them.   
 
I think we need to create a new "stored" instance of IProperty
for each stored Digital Subject regardless of which type of IProperty ("stored"
or "in-memory") was passed to setValue(). In this case there
will be no any two or more Subjects which refers to the same "stored"
instance of attribute, metadata or value. 
 
> Each Attribute in the data model is distinguished by it's Attribute
Type + Metadata combination.   
> The IAttribute would actually have to be populated with it's type
and all the metadata in order to 
> distinguish it from other attributes of the same type.
 
It is difficult to agree with it. We think that Attribute should not be
obliged to always have some (and unique) Metadata. Also we need to analize
metadata of all Attributes to define which Attribute should be updated,
that requires some time. From the other hand, if we call setValue() method
we know exactly which Attribute should be updated.
 
 
In addition, to resolve problems with multiple values (as simple as complex)
of attribute I propose to add some CollectionAttribute to IdAS model. So
we will have exactly one value for SimpleAttribute and for ComplexAttribute,
and resolve a problem with ComplexAttribute that now unable to have more
than one complex value. 
 
Thanks, 
Sergey Lyakhov 
----- Original Message ----- 
From: Jim
Sermersheim 
To: 'Higgins
(Trust Framework) Project developer discussions'
Sent: Tuesday, March 27, 2007 4:27 AM 
Subject: Re: [higgins-dev] IdAS is now Java 1.4 

>>> "Sergey Lyakhov" <slyakhov@xxxxxxxxxxxxxx>
3/26/07 2:17 PM >>>
>Jim,
>
>Now IProperty interface doesn't contain setValue method. As a result
we 
>unable to change a value of Attribute or Metadata directly. As I understand
>we need to use new UpdateOperation object to update a value of Attribute
or 
>Metadata of DigitalSubject. We need to make a lot of changes to implement
>new interfaces but it looks more complicated in using comparing with
>previous version. Please explain which benefits we will have using
this 
>approach. 
 
Let's assume there was a setValue method on IProperty.  What are the
exact semantics of it? 
- If the IProperty instance was gotten by the IdAS consumer by calling
IDigitalSubject.getAttribute, would setValue cause that value to be updated
on the underlying data at that point in time? 
- If the IProperty instance was gotten by the IdAS consumer by calling
IDigitalSubject.getAttribute.getMetadata, would setValue cause that value
to be updated on the underlying data at that point in time? 
- Same question for all other interfaces which extend IHasMetadata. 
 
Those are the easy questions, this is where it gets ugly: 
 
- If the IdAS consumer got the IProperty instance from IContext.buildAttribute,
and then called setValue, we can assume it sets the value only on the in-memory
IProperty instance (I think) 
- If the IdAS consumer got an IProperty instance from IContext.buildAttribute,
then used that IProperty instance to call IContext.addSubject, and after
that called setValue on the IProperty instance, does that update the value
on the new subject in the context? 
- If the IdAS consumer uses the same IProperty instance when creating two
Digital Subjects (via IContext.addSubject), and then calls setValue on
that IProperty instance, does it update both Digital Subjects? 
- If the IProperty instance was gotten by the IdAS consumer by calling
IDigitalSubject.getAttribute, and then used that IProperty instance to
create a new Digital Subject, would setValue update both Digital Subjects?
 
If we allow IProperty instances to be used to update the Digital Subjects
to which they are associated, it means Context Providers will need to maintain
associations between IProperty instances and the Digital Subject(s) to
which the IdAS consumer has associated them.  Further, there is nothing
for the IdAS consumer which would indicate whether calling setValue will
cause an immediate update to backing data. 
 
All of these questions had been asked at one point or another and remained
unanswered when I began refactoring the update operations.  Rather
than leaving them unanswered, I removed the set* methods.  When we
decide what the exact semantics are, and find useful applications, we can
re-introduce them. 
 
My preference would be that IPropertyValue.setValue only update that instance
of IPropertyValue and some other method would have to be called to update
any backing data store.  This might make things unnecessarily cumbersome
for a CP which only deals with in-memory objects, but I think it would
be better for most other CP's.  What do you think? 
 
>Also I do not see how we will update a metadata value of 
>Attribute. 
 
Correct.  I brought this up here http://dev.eclipse.org/mhonarc/lists/higgins-dev/msg01921.html,
and responded to it here http://dev.eclipse.org/mhonarc/lists/higgins-dev/msg01932.html.
 We need to talk about how attribute metadata is updated, and put
that ability back into the interfaces. 
 
> Also I do not understand how we can update an Attibute of 
>DigitalSubject using UpdateOperation if this subject has a few Attributes
of 
>the same type. 
I assume you're asking how the IdAS consumer distinguishes among those
Attributes (all of which have the same type. 
The UpdateOperation has (in this case), an IAttribute instance.  Each
Attribute in the data model is distinguished by it's Attribute Type + Metadata
combination.  The IAttribute would actually have to be populated with
it's type and all the metadata in order to distinguish it from other attributes
of the same type. 
 
I note that this seems cumbersome to some people (Tom and I had a long
talk about it a week ago, neither of us like it much).  This is a
case of the data model driving the design.  We may want to revisit
this aspect of the data model on this week's phone call. 
 
Again, thanks for the good feedback -- this is really helping to move things
along. 
 
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