RE: [provision] SPML 2.0 Relationships proposal...

["Jeff Bohren" <jbohren@opennetwork.com>]

Gary,

I apologize for responding. I've just been very busy lately.

There is way to avoid using a PSO to represent relationship attributes.
The problem is that it makes the relationship management verbs more
complicated. The trade off is basically between a simpler protocol with
more burden on the implementation vs. a more complicated protocol with
less burden on the implementation.

Jeff Bohren
Product Architect
OpenNetwork Technologies, Inc
 
Try the industry's only 100% .NET-enabled identity management software.
Download your free copy of Universal IdP Standard Edition today. Go to
www.opennetwork.com/eval.
 
 

-----Original Message-----
From: Gary P Cole [mailto:Gary.P.Cole@Sun.COM] 
Sent: Monday, August 09, 2004 2:42 PM
To: Jeff Bohren
Cc: provision@lists.oasis-open.org
Subject: Re: [provision] SPML 2.0 Relationships proposal...

Jeff,

I haven't seen your reply in this thread (I saw your reply to Gerry).  
Some of my points were unimportant, but I think #10 is worth addressing.

Gary P Cole wrote:

> Jeff Bohren wrote:
>
> Gary Cole wrote:
>
>> 10)  I really wish there were some way to avoid making the (optional)

>> relationship object a PSO (and giving it an ID).  As we discussed at 
>> Long Island, persistently storing these objects (and mapping each to
the
>> appropriate target object or API) creates scale problems for a 
>> provider.  Experience suggests that the number of connections may be 
>> an order of magnitude or more greater than the number of objects 
>> connected.
>>
>> Rather than identifying a complex connection by an ID, could we 
>> specify a complex connection instance by its From ID, To ID, and 
>> Connection Type?  If a provider can map these identifiers to the 
>> appropriate target
>> object or API, then we avoid persistently storing each complex 
>> connection object as a PSO (and continually having to map its ID).
>>
>> In the case of the RACF, these arguments map cleanly to the API.  In
the
>> case of a directory object, it might be necessary to find the
connection
>> object by starting at one end (either source or target) or by 
>> searching for an object that connects both the "fromID" and the
"toID".
>>
>> As a consequence, one would modify connection attributes by passing 
>> any object representing a complex connection as part of the 'connect'

>> request.  A single 'connect' verb could implicitly modify any 
>> existing connection between the specified "from" and "to" objects (as

>> it does in RACF), or we could define separate  verbs to 
>> "addConnection" and "modifyConnection".
>>
>> Do you see any problems with this kind of approach?  Is it possible 
>> to avoid representing each complex connection object as a PSO?
>>
>> [JSB] It is possible if the following restrictions are made:
>> 1) There can not be two references with the same "from" and "two" IDs
>> but with different attributes.
>>  
>>
> I think your first restriction should be reworded to:
> 1) There can not be two references _of_the_same_type_ with the same 
> "from" and "to" IDs.
> or
> 1) There can be at most one reference of a given type between two 
> objects A and B.
>
>> 2) The attributes are always updated as a set. In other words one RA
can
>> not try to set the "admin" attribute on the same relationship while
>> another is trying to set the "audited" attribute on the same
>> relationships.
>>  
>>
> I do not understand why the attributes would have to be updated as a 
> set.  In RACF-land, it is entirely appropriate for one caller to 
> modify the "SPECIAL" flag on a connection while another caller 
> modifies the "OPERATOR" flag on the same connection.  In LDAP-land, 
> can't one caller modify an attribute of a name while another caller 
> modifies another attribute of the same name?
>
> Can't a modification request specify the element or attribute it 
> intends to add, replace, or delete?
>
> I think I may know the source of our "disconnect".  You proposed 
> adding state to connections by adding a level of indirection.  What 
> you called the "Reference Attributes ID" is a reference to another 
> object that represents any "extra information" stored on the 
> connection.  In your proposal, that object is stored persistently as a

> PSO and is specified by a PSO ID.
>
> I like the idea of having an object that represents the "extra 
> information" stored on the connection, but  I'm trying to avoid 
> storing (and modifying) that object as a PSO (for the reasons of 
> performance and scale we discussed at Long Island).
>
> 1) If a connection object were passed as an optional argument to the 
> 'connect' request, then the connection object could be arbitrarily 
> complex. 2) A connection object passed into a 'connect' request could 
> also be used to update an existing connection: any specified element 
> or attribute would overwrite the corresponding element or attribute of

> the existing connection (as it does in RACF).  On the other hand, it 
> might be cleaner to have a separate operation to modify connections.  
> A 'modifyConnection' request could either replace the entire 
> connection object or could add, replace, or delete specific elements 
> or attributes of the connection object.   I don't care much how we do 
> this, as long as there is a way to do it.
>
> The big point is that a connection object (and modifications to a 
> connection object) can be mapped to an appropriate target object or 
> API  *without* having to store and identify the connection object 
> persistently.  Knowing the connection type, from id and to id is 
> enough.  This keeps the ID namespace and PSO storage requirements an 
> order of magnitude (or more) smaller.
>
>> I think trying to avoid making the attributes a PSO is going to cause
>> more effort on the implementers than it is going to save.
>>  
>>
> You may be right, but I don't see it yet.  I'm kinda slow that way.  
> What additional efforts do you foresee?