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