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] Community input on Future of Standards-Based Provisioning and SPML


Thank you for posting this, John. This statement by the SPML SIG  
certainly helps to frame our discussion.  In order to advance that  
discussion, it would be helpful to have a description of the   
"connector problem" and of the use-provisioning use-cases for cloud- 
based applications.  Would this SIG (or its members) be able to  
provide this kind of direction?

I like the idea of a simple profile, and I look forward to the  
development of a consensus.  Perhaps the concrete use-cases for  
provisioning to cloud-based applications will help to focus this  
profile and to limit some of the flexibility that participants in the  
specification of SPMLv2 and its DSML and XSD profiles required.  To  
that end, I offer a few comments and ask a few questions intended to  
clarify the "Back to Basics" description of the simple profile (inline  
below).

On Aug 25, 2010, at 3:31 PM, John, Anil wrote:

> All,
>
> I am sure that folks here have been tracking the conversation around  
> Standards based provisioning and SPML that was initiated by Mark  
> Diodati of Gartner/Burton Group and since then has continued both  
> online and at the SPML SIG that was held at the the Gartner/Burton  
> Group Catalyst Conference last month.  Mark recently posted the  
> notes of that meeting on his Gartner blog (http://blogs.gartner.com/mark-diodati/ 
> ) and the consensus agreement of the participants in the SIG (Full  
> Disclosure: I was a participant in the SIG)
>
> I wanted to make sure that it was provided to the SPML TC as input  
> into the TC Charter discussions we will soon be having (Full text  
> below as well as link to original entry)
>
> Regards,
>
> - Anil
>
> :-
> :- Anil John
> :- Johns Hopkins University - APL
> :- http://www.jhuapl.edu
> :- +1 240.228.0612
> :-
> :- E-Mail Response Time: 24 hrs
>
> ========================
>
> Consensus on the Future of Standards-Based Provisioning and SPML
> http://blogs.gartner.com/mark-diodati/2010/08/20/consensus-on-the-future-of-standards-based-provisioning-and-spml
> by Mark Diodati  |  August 20, 2010
>
> I had the honor of facilitating the Standards-Based Provisioning  
> Special Interest Group at this year’s Catalyst conference. The  
> participants believe that standards-based provisioning is at a  
> crossroads and wish to publish the following statement. The  
> statement is based upon our conversation; all of the participants  
> have reviewed it.  I hope that the perspectives of these industry  
> luminaries push the industry (and the especially the newly-reformed  
> OASIS Provisioning Services Technical Committee) towards a viable  
> provisioning standard.
>
> ——————————————————————————————————————-
>
> Moving Forward on Standards-Based Provisioning
> On Tuesday, July 27 a group met at the annual Burton Group North  
> America Conference in San Diego to discuss the future of  
> standardized provisioning and Service Provisioning Markup Language  
> (SPML). The group readily achieved a consensus about two things: the  
> need for standards-based provisioning and the qualities required for  
> successful provisioning standard. The following people participated  
> in the special interest group (SIG):
>
> Abdullah Haydar (Open Dealer Exchange)
> Andrew Ferguson (e2B2Bcom)
> Anil John (Johns Hopkins)
> Ash Motiwala (Identropy)
> Chuck Mortimore (salesforce.com)
> Jacob Farmer (Indiana University)
> Jonathan Sander (Quest)
> Mat Hamlin (SailPoint)
> Nick Nikols (Novell)
> Nishant Kaushik (Oracle)
> Steven Legg (e2B2Bcom)
> Tony Goulding (CA)
>
> The participants have firsthand experience with the difficulties of  
> proprietary provisioning from the perspective of both vendor and end- 
> user organizations. The SIG meeting was particularly timely, as the  
> Organization for the Advancement of Structured Information Standards  
> (OASIS) is evaluating the need for an SPML v3 standard.  
> Additionally, the SaaS market is at a critical juncture as vendors  
> look for standards-based solutions to the provisioning problem.
>
> SPML v2
>
> The second iteration of the SPML standard was approved in the spring  
> of 2006 and included additional capabilities and operational modes.  
> In trying to address every possible use case, interoperable  
> provisioning services leveraging the SPML v2 standard became  
> impractical. Since the approval, few (if any) conformant  
> implementations exist due to the complexity of the v2 standard.  
> Additionally, vendor participation in the OASIS Provisioning  
> Services Technical Committee (PSTC) has been nearly non-existent  
> since v2 was approved.
>
> Organizations wishing to use SPML must write provisioning services  
> specifically for each vendor’s SPML implementation (if the vendor  
> supports SPML at all). The difficulty in building a single,  
> interoperable provisioning service has made the adoption of SPML by  
> application developers a non-starter. Without adoption by enterprise  
> and cloud application developers, SPML will not be adopted. In  
> conclusion, the SPML v2 standard is broken.
>
> Back to Basics
>
> The next iteration of SPML should focus on solving “the connector  
> problem” and provisioning use cases for cloud-based applications.  
> That is, the next version of SPML should readily enable the  
> development of simple, standards-conformant provisioning services  
> for both enterprise and cloud applications.
>
> The participants agree that a standards-based provisioning protocol  
> is needed, and all concluded (except Chuck Mortimore) that it is  
> best to evolve the SPML standard rather than introduce a new one  
> (salesforce.com has not yet arrived at this conclusion). The next  
> iteration of SPML needs to become simpler. It must support a simple  
> use case for conformant, standards-based provisioning services.  
> Additionally, the SPML standard is too imbalanced; it places too  
> much burden on target applications. The participants assert that the  
> next version of SPML must possess a “simple” profile for to be  
> successful. The simple profile should include the following qualities:
>
> * Provide basic create, read, update and delete (CRUD) operations.

I assume this is a statement of required scope for the simple  
profile.  Aside from listTargets, these are the only operations that  
SPMLv2 requires.

> * Focus on the default use case of a single provisioning service  
> point (PSP) and provisioning service target (PST). This use case is  
> the default one for application developers and end-user organizations.

SPMLv2 optimizes the use-case of a single target by allowing the  
'targetId' parameter to be omitted when a provider exposes only a  
single target.  The listTargetsResponse for a minimal provider (or for  
a provider whose capabilities are well-known to the requestor) can be  
very terse.

In what other ways should the simple profile focus on this default use- 
case?

> * Eliminate transactional auditing requirements. In particular, the  
> Updates capability places an impractical data retention and  
> performance burden on the application.

The Updates Capability is optional.  No provider is required to  
support this capability.

> * Support a simple search mechanism. The current search mechanism  
> can create nearly infinite search parameters across all known user  
> attributes, which places an undue burden on the application.

The design point for the DSML Profile was LDAP search.  The design  
point for the XSD Profile was XPath search.  What would be the design  
point for search in the simple profile?

Is the goal to improve the convenience of simple searches for the  
requestor, or to simplify the search function that a provider must  
support?  If the goal is to simplify the search function that a  
provider MUST support, would conformance with the simple profile also  
restrict the search function that a provider MAY support?

> * Enforce conformance. Vendor’s products must undergo conformance  
> testing prove interoperability. Conformance likely requires a  
> reference implementation.

This seems like an excellent suggestion.  If we can define (and can  
agree to) a common set of behavior expectations, this should greatly  
simplify the process of developing and certifying a provider.  Would  
we want to do something similar for requesters?

> * Provide an optional, standard schema. An optional standard schema  
> (like LDAP’s inetorgperson) provides a potential schema for  
> immediate interoperability with other applications.

This sounds highly desirable.  If participants can define (and can  
agree to) a common set of attributes (and potentially common object- 
classes), this should greatly facilitate interoperability.

The first questions that occur to me are: Would this standard schema  
need to be extensible?  Would all attributes be required?  Would each  
predefined attributes imply a certain contract that the conformance  
tests could exercise?

>
> The Path Ahead
>
> It is up to vendor and end-user organizations to move the SPML  
> standard forward so that the industry can begin to build  
> interoperable provisioning services. If you are interested in  
> influencing the direction of standards-based provisioning and SPML,  
> please consider participating in the OASIS PSTC.
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail.  Follow this link to all your TCs in OASIS at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
>



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