[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [provision] SPML 2.0 Relationships proposal...
Okay, I think I follow you. Storing complex connections as PSOs simplifies the protocol (because you don't need a separate set of verbs to manipulate connections) but imposes more of a (persistence and mapping) burden on the implementation. This is the better approach if most connection types are simple. The benefit of keeping the protocol simple applies to everyone all the time, and the burden of representing each complex connection as a PSO applies when it is necessary to manage a complex connection type. Do I follow your reasoning correctly? Gary Jeff Bohren wrote: >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? >> >> > > > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]