One example of containment that can not be modified is no leaf nodes in
most LDAP servers. If the SPML service front ends an LDAP server, then for most
LDAP servers:
add (ou1, ou1data)
setParent (ou1, org1)
add (ou1-1, ou1-1data)
setParent (ou1-1, ou1)
works, but:
add (ou1, ou1data)
add (ou1-1, ou1-1data)
setParent (ou1-1, ou1)
setParent (ou1, org1)
fails.
I think it is a mistake to view containment and reference as generic
relationships (or roles if you prefer). Containment in particular has a very
real impact in the provisioned resource. For instance if the underlying resource
is a directory then new PSO must be placed under some container if it is not
specified. Having to specify a create and a set containment in multiple
requests, even if they are batched, will result in a very poor
provisioning system.
For instance suppose an RA is going to onboard a set up users using an LDAP
backended SPML service. Suppose there are 1000 users in the batch request:
add (uid1, user1data)
setParent (uid1, ou1)
add (uid2, user2data)
setParent (uid2, ou1)
...
add (uid1000, user1000data)
setParent (uid1000, ou1)
So for one thousand iterations the user has to be created in an arbitrary
container and then moved to the correct container. Since the proper container is
known at creation time, this seem unreasonable. Also what happens if the service
goes down after creating a user but before moving it? That's certainly fixable,
but it would be simpler if the user was created in the proper container to begin
with. Given the choice between doing containment explicitly but with this
unreasonable extra overhead, or doing it implicitly, I believe that most
implementors with just take the easier route and do it implicitly.
If when creating a PSO, if the data, container, and any relationships are
known at creating time, why not create the PSO with all the available
information? Why make the processing more complicated?
In part I agree that extending the core verbs is not the best solution. For
containment I would still prefer to have containment part of the
core. Since the rest of the TC did not agree to that, extending the core
verbs was may next solution. I can see good arguments both for an against
putting references in the core, and I could go either way on that issue.
I agree that searching by reference as I have proposed in complicated, but
I have not seen a simpler proposal. I see searching by references as a must have
if I was going to implement explicit references in an SPML services. If I could
not search by explicit references, I would simple make them implicit which is
easier anyway.
Jeff Bohren
OpenNetwork Technologies
-----Original Message-----
From: Gearard Woods
[mailto:]
Sent: Wed 8/4/2004 2:01 PM
To: Jeff Bohren
Cc:
Subject: RE: [provision] SPML 2.0 Relationships
proposal...
Jeff,
My understanding was that the reason we wanted creation of
containment relationships at the same time as the PSO was to address problems
with things like groupOfNames or groupOfUniqueNames, that require a member to
be specified. At least that was the discussion I remember from the F2F. I
don't necessarily think that this is reason enough to shape the whole
relationship approach though. I'm not sure what other resources make
containment immutable. Perhaps an example would be persuasive.
I think
the terminology I used in my suggestion is causing some misunderstandings. In
the COS Relationship interface, a relationship is defined as a collection of
roles. These are not roles in the sense used in the provisioning world, they
are the roles that objects play in a given relationship. "Contained" is a
role, for example, and "Contains" is a role. A Containment relationship is
comprised of these roles. It sounds like you didn't get a chance to look at
the schema I sent out, which should make this clear, but maybe a name change
would help if it's still confusing. There are, in my mind, very few
restrictions placed on users of the relationship model I suggested and
certainly all of your examples can be easily accommodated. I think it might be
more extensible even.
The argument for doing a create of an object and
its relationship in a single operation is a good one. Perhaps the use of a
relationship operation in a batch would satisfy us both. Fundamentally, I'm
just not keen on the idea of extending core requests such as add, modify, and
search to incorporate different kinds of relationships. It seems inconsistent
to me to use one operation when you want to just add an item, and another when
you want to add it and and do something else. And search seems very
convoluted. I'm not sure it's a good pattern to propagate in future
capabilities either. What I'd prefer would be that there is a single,
consitent way to manipulate objects and a capability providing a single
consistent way to manage relationships. Overloading a basic set of operations
might seem simpler but I don't think it always leads to the appropriate
interface for a given application.
Gerry
'
src="gif00018.gif" width=16>"Jeff Bohren"
<>
"Jeff Bohren"
<>
08/03/2004 08:05 PM
To:
<>
cc:
Subject: RE: [provision]
SPML 2.0 Relationships
proposal...
You are correct that there is no hard requirement that you be
able to create a reference on a PSO when you create it. However this is often
a hard requirement for containment. In many resources the containment of a PSO
is immutable once the PSO is created.
I do not agree with
using role relationships explicitly. While role is one commonly used kind of
reference relationship, it is only one of many. For instance PSO representing
a computing resource might be “owned” by a PSO for a user. There could be a
reference to a core identity PSO to all of the PSOs representing its
provisioned accounts. A mainframe account PSO could have references to the
PSOs representing terminals that the user can log in from. Expressing
reference relationships in terms of roles is just far too
restrictive.
To me setting and removing relationships on an
existing PSO is a kind of modification. I don’t see any reason why you should
not be able to add a reference and an attribute to a PSO in the same request.
I also don’t see why you should not be able to create a PSO with both
attributes and relationships. If you know all of the information about a PSO
at creation time, then why shouldn’t it be one request? That seems much
simpler to me. As in my previous email, I see the operations
as:
Add (id, data)
Add
(container, id, data)
Add (container,
id, data, references)
Modify (id,
data)
Modify (id, data,
references)
Move (id,
container)
Why make it more complicated that
this?
I was not assuming that we don’t use full XPath expressiveness.
The problem I was trying to solve is how to create a search query that
combines the XPath expressions needed to select based on the PSO data with the
expressions needed to select based on the PSO reference information. If you
can suggest a way to do that with only XPath, I would be open to
it.
I agree we still have more work to do on the modify request. I
will also take a look the modification type problem.
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: Gearard Woods [mailto:]
Sent:
Tuesday, August 03, 2004 5:16 PM
To: Jeff
Bohren
Cc:
Subject: Re: [provision] SPML
2.0 Relationships proposal...
Jeff,
It's great to have a straw
man to focus on. I just have a few comments and questions. It seems to me
that the approach of extending core operations, particularly for add, is
driven mostly by the problem that we discussed at the F2F, i.e. the need
to have a PSO available when the relationship is created. Is this really a
valid constraint to place on ourselves? I'd like to revisit this because I
would prefer that we not use derived operations in general - my preference
would be for a relationship interface that is not so coupled to the core
operations. For example, I was imagining something similar to the Cos
Relationships model. In that world view, a relationship is simply a
collection of roles. I've attached a schema that reflects something like
the same model. If we were to follow in spirit of this approach, the
schema would be accompanied by an operational interface primarily
consisting of operations like:
Relationship create(Roles
roles);
Relationship add(Relationship relationship, Role
role);
Relationship remove(Relationship relationship, Role
role);
Relationships remove(Role role);
Relationships
getRelationships(PSOIdentifier pso, Role role);
Relationships
getRelationships(PSOIdentifier pso);
Roles getRoles(PSOIdentifier
pso);
...and so on, or something like it.
There are a couple
of things in the proposal that reflect problems that I see in the core
schema:
1. Modifications. We still have not fully filled out the
modification portions of the schema.
2. Search. We talked before about
being more specific in the definition of a search syntax. I am still in
favour of doing that. When I was suggesting a subset of XPath though, I
wasn't suggesting that we eliminate all of the XPath expressions. In
particular I think it would make sense to keep the boolean expressions
(and, or, !=, =, <=, <, >, >=). If we did opt for a
well-defined XPath-like syntax then it wouldn't make sense in my mind to
redefine these types of expressions here. This whole subject warrants more
discussion in my view.
By the way, there seems to be an error on
line 138 of version 5 of the schema. I think
'type="spml:ModifyRequestType"' should in fact be
'type="spml:ModificationType"'. Also, on line 189 the use of an element
and an any in the sequence is problematic. I changed the "appliesTo"
element to an attribute to get around this.
Gerry
(See attached file:
relationship_example.xsd)
'
src="gif00019.gif" width=16>"Jeff
Bohren" <>
"Jeff Bohren"
<>
08/02/2004 09:36
PM
To:
<>
cc:
Subject: [provision]
SPML 2.0 Relationships proposal...
Attached is the
first draft of my proposal for handling relationships. This covers both
containment and references. It supports references with attributes. It
also supports relationships (both kinds) as search criteria and also as
search results. I believe that this proposal meets all of the requirements
discussed so far.
This proposal is based on draft 5 of the
SPML 2.0 schema.
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.
To unsubscribe from this mailing list (and be
removed from the roster of the OASIS TC), go to http://www.oasis-open.org/apps/org/workgroup/provision/members/leave_workgroup.php.
#### ONT Relationships
Proposal v1.doc has been removed from this note on August 03, 2004 by
Gearard Woods
<<pic23083.gif>>
