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>>