OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

provision message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: RE: [provision] SPML 2.0 Use Case doc, first draft...

Maybe I could just outline what I'm suggesting by throwing out a few examples without any detail:

1. Provision a resource
1a. Schedule the provisioning of a resource at some time in the future
2. Deprovision a resource
2a. Schedule the deprovisioning of a resource at some time in the future
3. Modify provisioned data associated with a provisioned resource
4. Query available targets
5. Query target schema
6. Query provisioned resources
7. Modify the state of a provisioned resource
7a. Suspend
7b. Restore
8 Query the state of a provisioned resource
9. Create and query relationships between provisioned data instances or targets
9a. Create/query hierarchical organizations
9b. Create/query dependancy graphs
9c. Create/query groups
10. Federate heterogeneous (multi vendor) or homogenous (single vendor) provisioning systems
10a. Vendor A PSP provision to Vendor B PSP

Apologies for avoiding the PSTC acronyms for the most part but I find that they can be kind of confusing at times. The original use cases can still be effectively captured in 1-6 but I would like to get away from the complexity of who creates what ID where. I'm not sure those separate use cases were very helpful in describing the problem domain in any case. 1a and 2a have been suggested by Gary's model where times for activation and de-activation have been in the schema. There has been a lot of discussion regarding state so #7 and #8 might speak to that and could encompass your D1-D2. #9 is essentially your C1-C3 but I would prefer to model relationships in general since I think they have great value in this domain. The federation use cases reflect your B1-B2 but our scenarios do not have a strict sequence of messages visible through the external interface so I think this should be a little more general. Perhaps these might form the basis of an interoperability discussion? I'm sure other people have better interoperability use cases.

These are not intended to negate your document but just to offer a slightly different view. In my opinion, at the level of a use case things should be fairly general and easy to understand. I found the proliferation of use cases based on the generation of PSO-IDs very distracting in the original document and did not lead to an understanding of the real problems that the SPML was trying to solve.

Inactive hide details for "Jeff Bohren" <jbohren@opennetwork.com>"Jeff Bohren" <jbohren@opennetwork.com>

          "Jeff Bohren" <jbohren@opennetwork.com>

          04/06/2004 10:51 AM

To: <provision@lists.oasis-open.org>
Subject: RE: [provision] SPML 2.0 Use Case doc, first draft...

I don't mind revisiting the "Basic Use Cases" (SPML 1.0 Use Cases). I think that Gerry has a good point about the level of detail.

But one important point to remember is that the Use Cases are not requirements. The point of the Use Cases is to capture the problem space that we are trying to solve. In that context organizational hierarchy is an important use case that should be captured. Whether or not that is ever explicitly reflected in SPML 2.0 is another issue entirely.

If anyone would like to suggest better use cases for the "Basic Use Cases" post your suggestions (or send them to me directly) and I will try to incorporate them into the Use Cases document. The we can go through the document and scrub out the ones that seem to be duplicate or unnecessary.

Jeff Bohren
Product Architect
OpenNetwork Technologies, Inc

Try the industry's only 100% .NET-enabled identity management software. Download your free copy of Universal IdP Standard Edition today. Go to www.opennetwork.com/eval.

GIF image

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]