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