RE: [provision] Reuse in SPML

[Jeff Bohren <jbohren@opennetwork.com>]

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>