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