[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
[higgins-dev] What happened to createSubject()?
|
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