[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
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>
03/25/2004 02:20 PM | To: Gearard Woods/Irvine/IBM@IBMUS, "Jeff Bohren" <jbohren@opennetwork.com> cc: "Gary Cole" <Gary.Cole@waveset.com>, <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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]