Could we discuss the identification
attributes for a minute, because I think that sets the stage for the
discussion of state attributes?
In the email that teed this all up, I
wrote:
>
>
To identify the account, Account has "target",
"name",
> and "guid" attributes. The account is usually
associated
> with some target, has a name that is changeable,
and
> may have an internal identifier
>
that is not supposed to change.
>
When I say "Account", I think of this as
roughly equivalent to "ProvisionedObject". (I realize that not
all features of Account apply to every provisioned object, but
this doesn't bother me too much because not all features of Account
apply to every account. Target accounts all different,
but there are also common features.)
Not every target supports "guid", but
it's common enough (especially among the modern targets) that it's
reasonable to model this as a common feature. We can simply
leave "guid" null or empty where it is unknown or
unsupported.
I don't want to leave this
"open" (i.e., an entirely arbitrary
attribute) because guid is pretty common and very
useful in managing the account. Where guid is supported, it is
the preferred identifier. It is *very* handy to keep a guid as a
native identifier, since this helps in detecting native renames (and
distinguishing a 'move' from a 'delete' and an 'add'). Where the
target supports some kind of guid, I want to map that value to an
attribute that my management code recognizes.
I'm guessing that everybody basically
buys this premise, because the discussion has centered on the
state-related attributes. Here's the part where I step off the
ledge...
I think of the state-related attributes
we've been discussing in the same way: common and useful where
supported, harmless and empty if unsupported. For example, it doesn't bother me at all if a
particular class of provisioned object doesn't support "disabled", as
long as the value that comes back is harmless (e.g., empty or
"NOT_SUPPORTED").
It's common enough (not just for
accounts, but also for policies and other objects) to add
objects disabled and then enable them at a later date. This
is such a common aspect of management that I'd prefer to model this
explictly as a well-known aspect of state.
I'm interested to know what everyone
thinks. I'm not sure everyone will agree with this line of
reasoning, but if this explains where I'm coming from, then maybe you
all can use it to explain things to me.
Gary
----- Original Message -----
Sent: Friday, March 26, 2004
9:32 AM
Subject: Re: [provision]
PSO/Account/ProvisionedState
This sounds
interesting. Defining multiple interfaces (as Gerry
suggests) sounds like a reasonable way to tease apart the facets
that interest some (but not necessarily all) of us. Tying
these to a common schema (as Jeff B suggests) seems like a
reasonable way to keep the whole thing from flying
apart.
I need a little more help
imagining how we'd structure this. I wanted to define a
bunch of common state-related attributes, but Jeff B and others
point out that not all of these apply to all types of
accounts. Perhaps none of these state-related attributes
(beyond "exists") apply to some kinds of provisioned
object.
I had imagined calling a method
like:
State
getProvisionedState(PSO-ID);
For an Account, I'd get back all the
attributes that apply:
<State psoId='ID'
exists='true' disabled='false' disableDate='NONE'
enableDate='NONE' expired='false' expireDate='DATE'
/>
For a provisioned object that supports
only "exists", I'd get back only "exists":
<State psoId='ID'
exists='true'/>
But it sounds to me from the discussion
above, that I might have to define a different schema for each
combination of attributes. Am I right about that, or could
'Stateful' contain our "starter kit" of common state-related
attributes?
Would each kind of provisioned
object have to define in its schema which state-related attributes
it supports?
Or would I just call a different method
(e.g., #listSupportedStateAttributes)?
Or could I figure this out just
from the set of attributes returned by
#getProvisionedState(PSO-ID)?
Sorry if I'm misunderstanding
your suggestion. If so,
perhaps we should talk offline (rather than email
everyone).
Gary
----- Original Message -----
Sent: Thursday, March 25,
2004 7:51 PM
Subject: RE: [provision]
PSO/Account/ProvisionedState
I would not be opposed to having mulitple provisioning
interfaces, provided it was tied to a standard schema that
normatively defined what interfaces where appropriate for what
object classes. The clients still need to know what interfaces
would apply to what PSOs.
For example the SPML core operations could apply to all
object classes but the SPML state operations may only apply to an
object class that inherits from a "Stateful" object class in a
standard schema (note that SPML 1.0 supports multiple inheritance
so this is easy). This way the schema for the resource does not
even need to extend an abitrary "Account" schema, it merely needs
to extend the "Stateful" schema.
Jeff Bohren
OpenNetwork
-----Original Message-----
From:
Gearard Woods [mailto:gewoods@us.ibm.com]
Sent: Thu
3/25/2004 6:01 PM
To: Jeff Larson
Cc: Gary
Cole; Jeff Bohren; provision@lists.oasis-open.org
Subject: RE: [provision]
PSO/Account/ProvisionedState
I agree that granularity of the calls is important and it
really shouldn't take 42 calls to determine the state of an
object - a single call should suffice. I think we can model
state effectively and still minimize the traffic needed to
manage it.
Jeff (Jeff B) has also raised the slippery
slope argument, and my take on it is that we should provide an
interoperable way to do the things we feel are a core part of
the provisioning process. There is a line here between what is
horizontal to provisioning and what is resource-specific. State
management is obviously important and passwords have come up
before, although Jeff B would argue that state is not even
relevant to most resources and is only applicable to accounts.
The provisioning process is obviously not the same thing
to all people. We have disagreement even down to the
fundamentals of the provisioning model. Perhaps a way to tackle
these different viewpoints is to divide and conquer. Imagine
that we split up the problem into a number of
interfaces:
SPML core - Basic provision (add),
deprovision (delete), modify, list/search
SPML state - An
interface and schema representing state management (lifecycle
included or separate?)
SPML events - An interface and schema
for event notifications
SPML password - Password management
perhaps
SPML relationships - TBD
Implementors must
publish core to be SPML compliant. They may then in turn overlay
any of the other interfaces to offer enhanced provisioning
capabilities. These would be simple interfaces with minimal
schema but would be complementary and all take advantage of the
core schema. Vendors who deal with directory-style interfaces
need go no further than the core interface while others may wish
to offer the full suite. Obviously these categories are just off
the top of my head but does this sound like an approach that has
promise?
Gerry
"Jeff Larson"
<Jeff.Larson@waveset.com>
I haven't been following this that
closely, but I like aspects of both approaches. I
like
the notion that
you can carry out near-universal operations like disable,
enable, and expire,
in
a schema independent way. But I also like the notion that I can
at least obtain the current state
from the model so I don't have to make 42 web
services calls to get everything I want to
display.
I guess as long as the schema is arbitrary we can
have it both ways. If I choose
to use fine grained standard operations I can. If
the PSP exposes the same functionality
through the model, I can use that too,
though I will be outside of the SPML spec.
But we're on a
slippery slope here. Almost every account will have an
associated
password,
email address, and full name. Do we then provide individual
operations
to get and
set those so we can access them in an standard way without
having to be
bothered
with PSP specific schema? How far does this go?
Jeff
-----Original Message-----
From: Gearard Woods
[mailto:gewoods@us.ibm.com]
Sent: Thursday, March 25, 2004 3:35 PM
To: Jeff
Bohren
Cc: Gary Cole;
provision@lists.oasis-open.org
Subject: RE:
[provision] PSO/Account/ProvisionedState
I think there's a fundamental difference here
even though the intent may be the same. Basically, we're all
trying to model state and provide some kind of standardized view
of it to the outside world so that we can offer
interoperability. By placing state in the resource schema you
have immediately abandoned the possibility that arbitrary
resource schema may be supported, which I believe to be
important. You are also now requiring a mapping from the
"standard" schema to the real resource schema. On the other
hand, by placing the emphasis on the service provider and
providing an operational interface to effect state changes, the
provider can now apply its knowledge of the resource to make the
state change however it wishes to do so and places no
restrictions on the resource schema.
Gerry
<<pic13953.gif>>