RE: [provision] Reuse in SPML

[Jeff Bohren <jbohren@opennetwork.com>]

I personally feel that everyones views should be considered regardless of how much time they have spent working on the TC, so long as they are serious contributions. If there are a number of people that feel that we have accomplished so far is not the right solution, we should take the time to work this out. Even though I have put a lot of work into this, I don't want to put forth a specification that only gets adopted by two or three companies. Of course the price for this is to miss the oportunity for a Burton Catalyst Interop event.
 
Darran, should we add time to Monday's agenda to talk about Gerry and Conrads concerns?
 
Having said that, let me outline my reasons that I think we do have the right solution. It may not be the best solution, but I doubt we as a committee would ever find the best solution anyway. Committees never find the best solution for anything. Anyway, here is my case for our current approach:
 
Practicality - I know from personal experience that the DSML/LDAP model works for provisioning. It is as simple as that. It works. We can invent lots alternative solutions, but if we built a spec around one of them, how confident would we be that after the spec is ratified, it would work in practice? We currently have a model that has been demostrated to work in practice, not just in theory.
 
Industry Acceptance - forget about DSML for the moment. The concept of representing accounts as name/value pairs is widely accepted among the types of resource that need to be provisioned. JNDI has achieved widespread usage, and not just for LDAP. LDAP is being adopted at an astonishing rate. MS seems to be slowly moving all of it's major server identity stores to AD (at least as an option). Most commercial IT systems now support LDAP as an option. Most of the commercial provisioning systems are either LDAP enabled, support LDAP in some fashion, leverage meta-directories, or have a virtual directory front end. DSML itself is starting to gain traction, with a JNDI SP available from Sun, a DSML gateway for AD from MS, a DSML gateway for eDirectory from Novell, announced DSML support in MMS 3.0, and of course the DSML based provisioning web service from OpenNetwork Technologies. And then there are the other XML provisioning specifications that are LDAP related, such as the Access360 DAML spec and the Novell DirXML spec.
 
Theoretical Advantages - one way to look at provisioning is as a federated namespace problem. A typical provisioning system maintains an internal model of the provisioning namespace and synchronizes that namespace with the external systems. The LDAP model does have inherent limitations, but those limitations are also it's strength. Because there are limits to how the namespace can be represented and what operations are available, there is semantic predictability of the operations. When a PSP makes an add, modify, or delete request to a PST, there is predictability as to how that PST will behave. The  PSP should be able to make reasonble assumptions about the post-operation state of the PST namespace without having to do a reconciliation. This is why I have tried to downplay the extended requests. By thier very nature the do not have sementic predictability. You could create a provisioning system that could use any PST web service that had a WSDL definition, but such flexibility would make interoperability very difficult. Likewise doing everything through extended requests will have the same result.
 
Mature Proven Track Record - SPML is derived from DSML v2, which is derived from DSML v1,  which is derived fro LDAP, which is a derived from X.500. X.500 and LDAP both have a long successful track record. Simply put, they work. They work well. 
 
Finally, I would like to pose the question: What do we gain by not using the DSML/LDAP model?
 
Jeff Bohren
 
 
 
-----Original Message----- 
From: Conrad Agramont [mailto:conrada@microsoft.com] 
Sent: Wed 2/26/2003 6:02 PM 
To: Gearard Woods; Jeff Bohren 
Cc: provision@lists.oasis-open.org 
Subject: RE: [provision] Reuse in SPML



	I have also been very absent from much of these conversations and much
	of it has to do with the discussion in this thread.
	
	I don't think that the requirement of matching the model to DSML closely
	for mindshare reasons is justified for what needs to be done.  As I've
	stated before in previous meeting, we should be focused on providing a
	model that fits the need directly and not derail the innovation by
	trying to align too closely another standard that is not offering a
	great deal of leverage.
	
	I also understand that this type of functionality is working within
	OpenNetwork's product today, but does this mean that it's the right
	model that the entire industry should be moving towards?  OpenNetwork's
	decision to leverage DSML could be contributed to the lack of an SPML
	model being readily available.  So by providing an SPML model that looks
	like DSML might be great for OpenNetwork or anyone else that has done
	the same, but for the future of SPML is this the right way to go?
	
	Now this may be a bit late in the game, but I agree with Gearard that we
	should really put a little bit more time to decide if this is the model
	that we want presented to the industry as our recommendation for a
	provisioning schema.
	
	Thanks,
	Conrad Agramont
	Program Manager
	Microsoft Corporation
	
	-----Original Message-----
	From: Gearard Woods [mailto:gewoods@us.ibm.com]
	Sent: Monday, February 24, 2003 10:46 PM
	To: Jeff Bohren
	Cc: provision@lists.oasis-open.org
	
	
	
	
	
	Thanks for the reply Jeff and of course I agree with you, directories
	are
	well understood and there are plenty of examples of provisioning systems
	that take advantage of directory-centric protocols such as DSML (and
	DAML
	for that matter).  I don't want to turn this into a big debate when you
	guys are so close to finalising something but as a potential
	user/implementor of SPML, I want to put in my two cents in an attempt to
	make sure that we don't end up suffering from the shortcomings of
	directory-centric protocols that we, and you, have tolerated for so
	long.
	As I said, I can understand the argument for filters, and DsmlMessages
	are
	minimal (an argument against coupling I thought, and what about those
	controls?).  What pains me more is the schema limitations of LDAP,
	particularly when you want to talk about more complex entities than
	attributes and values.  I know that the committee understands these
	limitations of directories - the enhanced schema for extended operations
	reflects that.  In my mind though, the ability to specify operations is
	only one side of the coin (and I would argue that there are more
	tool-friendly ways of doing it), complex types is the other.
	
	You'll have to forgive me but I don't buy the midshare argument for
	anyone
	but the most high level marketing types.  There are plenty of examples,
	and
	for this you need look no farther than the wealth of Java APIs, where
	developers are more than happy to adopt unfamiliar concepts when the
	ideas
	match the problem, or at least model it adequately.  And I don't have to
	point out to this group that the world is tooling up rapidly for WSDL
	and
	XML-Schema based Web Services.  Portal servers that understand WSDL as
	their essential lingua franca are being adopted like hot cakes and those
	just require an appropriate API, not a familiar one.  I'm not being a
	complete nay-sayer here, I think that it could be easy to transition to
	this kind of approach if there is a will and we bear it in mind before
	we
	commit anything to stone.
	Gerry
	
	
	
	|---------+---------------------------->
	|         |           Jeff Bohren      |
	|         |           <jbohren@opennetw|
	|         |           ork.com>         |
	|         |                            |
	|         |           02/24/2003 06:32 |
	|         |           PM               |
	|         |                            |
	|---------+---------------------------->
	
	>-----------------------------------------------------------------------
	-------------------------------------------------------|
	  |
	|
	  |       To:       provision@lists.oasis-open.org
	|
	  |       cc:
	|
	  |       Subject:  RE: [provision] Reuse in SPML
	|
	  |
	|
	
	>-----------------------------------------------------------------------
	-------------------------------------------------------|
	
	
	
	
	
	From the OpenNetwork Technology perspective, the DSML approach is
	working
	quite nicely. We already have a provisioning web service (PST) based on
	DSML (http://www.opennetwork.com/solutions/standards/dotnetconnected/).
	It
	will be a natural progression to extend this to support SPML as well.
	
	Although DSMLMessage is extended, it is really not core to the SPML
	concepts and could easily be replaced. What is leveraged in SPML is:
	
	Search Filters
	Attributes
	Modifications
	
	That may not seem like a lot, but the cost is very low, so why not? We
	coudl very easily replicate the parts of DSML we are using and no depend
	on
	it any more, but I don't see any tangible benefit in doing so.
	
	Of course the real benefit is not is saving a few element definitions,
	but
	in the mind share that is gained by explaining Provisioning in terms of
	a
	model than many already understand. The concept of representing
	provisioned
	using LDAP like constructs seems to be a good fit for most provisioning
	systems.
	
	Jeff Bohren
	OpenNetwork Technologies
	
	             -----Original Message-----
	             From: Gearard Woods [mailto:gewoods@us.ibm.com]
	             Sent: Mon 2/24/2003 5:29 PM
	             To: provision@lists.oasis-open.org
	             Cc:
	             Subject: [provision] Reuse in SPML
	
	
	
	
	
	
	
	             I've been absent from the discussion for a while so I
	apologise if this is
	             an old chestnut but following on the heels of Matthias'
	question about
	             batch operations in SPML, I'd like to ask the committee if
	the
	advantages
	             of maintaining the dependency on DSML are really working
	out?
	I can
	             certainly understand the argument for the use of the DSML
	Filter, athough
	             that could be adressed if necessary, but I'm more curious
	about the use of
	             DsmlMessages.  As everyone knows, DsmlMessages really
	encapsulate a set of
	             controls and an optional request ID.  This is such a
	trivial
	class and all
	             of the SPML messages are derived from it so it seems to me
	that SPML is
	             building in a dependency for very little gain in this case.
	This also
	             raises the issue of discovery of supported controls, as
	with
	LDAP/DSML.  In
	             LDAP of course, the specification calls for the server to
	provide a root
	             DSE where vendors generally publish the set of supported
	controls and
	             extensions.  I notice that the SPML schema includes the
	ability to define
	             extended operations but I don't see a place for controls.
	
	             I've been trying to catch up on the minutes of the meetings
	that I've
	             missed but I don't see any discussion so far of the use of
	yet
	another
	             schema language.  Propagating an LDAP style schema language
	when the
	             specification is written in a more expressive language,
	XML-Schema, seems a
	             little anachronistic to me.  I'm sure there is a reason,
	and
	I'm sure there
	             was discussion on the subject, but it appears on the
	surface
	that a lot of
	             time could be saved by re-using XML-Schema rather that
	re-defining another
	             schema langauge in XML-Schema.  This leads to my final
	question on
	             appropriate re-use and that is the definition of extended
	operations in a
	             world where considerable effort and tool support has been
	put
	into the
	             WSDL.  For that matter, it seems likely to me that the SPML
	might be
	             frequently used within an WSDL context.  In that case, the
	batch request
	             and response mechanisms adopted from DSML don't seem very
	useful and
	             extended operations would more naturally be defined using
	WSDL's
	             capabilities.
	
	             Again, apologies if I'm covering old ground,
	             Gerry
	
	
	
	----------------------------------------------------------------
	             To subscribe or unsubscribe from this elist use the
	subscription
	             manager: <http://lists.oasis-open.org/ob/adm.pl>
	
	
	
	----------------------------------------------------------------
	To subscribe or unsubscribe from this elist use the subscription
	manager: <http://lists.oasis-open.org/ob/adm.pl>
	
	
	
	
	----------------------------------------------------------------
	To subscribe or unsubscribe from this elist use the subscription
	manager: <http://lists.oasis-open.org/ob/adm.pl>