[provision] RE: SPML should be Schema+WSDL

[Jeff Bohren <jbohren@opennetwork.com>]

Gerry,
 
I think you are right in moving this thread back onto the mail list. 
 
As far as how close companies are to implementing the current SPML spec, I can't say in general. What I can tell you is the Netegrity and Business Layers have announced a demo of SPML at the RSA conference April 13-17. See:
 
http://www.infoworld.com/article/03/02/11/HNbusinesslayerssplm_1.html
 
Obviouslly I can not tell you how far along other efforts are until those efforts are publicly disclosed, but I think it is safe to say that there companies that are working on this based on the current spec. I do not think it will be long before you see reference implementations start to appear (unless, of course, we start over).
 
Also, there are a lot more examples floating around than what Yoav has posted to the mail list, so I would not judge the progress based on that.
 
I would be glad to see an exercise comparing the two approaches performed as you suggest, but I don't think that current efforts should stop because of it. If you fleshed out your proposal some more, I would be more than happy to participate in that exercise. We could take some of the use cases and try them out with each proposal. The would be an excellent learning experience regardless of how it turns out.
 
Jeff Bohren
OpenNetwork Technologies

	-----Original Message----- 
	From: Gearard Woods [mailto:gewoods@us.ibm.com] 
	Sent: Fri 2/28/2003 6:39 PM 
	To: Jeff Bohren; DeSouza, Edwin 
	Cc: provision@lists.oasis-open.org 
	Subject: RE: SPML should be Schema+WSDL
	
	





	Sorry, but I really feel this discussion should be on the list for anyone
	seeking clarification of the debate so I'm copying it there.
	
	Jeff is correct in that with my proposed approach, there would be a
	well-defined service interface that would be the SPML protocol, not simply
	the suggestion that SMPL is WSDL.  The protocol would comprise a set of
	schema documents (XML-Schema) representing the object model of the SPML,
	and a set of WSDL files describing the service level interface to (roughly)
	the actors or participants identified in the PSTC Use Cases.  Where I would
	disagree with Jeff is on the tool support for this approach.  Obviously,
	there are tools that would be able to interpret the WSDL and XML-Schema
	definitions for the raw remote procedure call aspects of this type of
	solution.  I think Jeff feels that the schema that is in turn published by
	targets would not benefit from those same tools but I'm not sure about
	that.  My perpective is that if you have to have XML-Schema  knowledge in
	any case, the same facilities can be used to interpret the target schema.
	
	The question of interoperability is important and here my argument would be
	that interoperability at the protocol level is possible because of the
	well-defined SPML API and object model.  The target object model (i.e. the
	schema for a specific target, say Exchange) is a different matter because
	that pertains to entities that are outside the scope of the specification
	and that is true if you are using a directory view of the world or this
	kind of scheme.  If a target elects to use a schema language that, for
	example, an RA does not understand then there is an incompatibility and the
	RA either gets smarter about the particular schema language or the target
	publishes its schema in a different language.  In fact, in my little
	example there is nothing to stop a target publishing its schema in multiple
	schema languages to accomodate different kinds of clients.
	
	The level of difficulty is really hard to guage for each approach.  On the
	one hand, Jeff's proposal might be able to leverage exisiting
	DSML/directory knowledge but will, I submit, place more of a burden on the
	client.  The kind of approach that I'm suggesting would benefit from the
	ease with which an interface can be generated from a Session EJB, for
	example, and the wealth of tools that clients can use to talk to a
	WSDL-defined service.  I'm tempted to say that this is a wash but we would
	have to undertake a prototype implementation in each, if only on paper, to
	get a more profound understanding of the difficulties.
	
	As far as the practical issues go, I can certainly understand the
	reluctance to change approaches at this stage but does anyone have a good
	handle on exactly how close the committee members are to a reference
	implementation?  With all due respect, if Yoav's recent XML examples are a
	reflection of the state of play then there is ample opportunity to indulge
	in at least a paper exercise to compare the two approaches.  An experiment
	like that would show up any real flaws in both and would, I think, give the
	committee even more credibility.  At the very least it would drive the
	creation of some useful examples for the documentation.
	Gerry
	
	
	
	|---------+---------------------------->
	|         |           "Jeff Bohren"    |
	|         |           <jbohren@opennetw|
	|         |           ork.com>         |
	|         |                            |
	|         |           02/28/2003 10:50 |
	|         |           AM               |
	|         |                            |
	|---------+---------------------------->
	  >------------------------------------------------------------------------------------------------------------------------------|
	  |                                                                                                                              |
	  |       To:       "DeSouza, Edwin" <edesouza@jamcracker.com>, <Darran.Rolls@waveset.com>, <Gavenraj.Sodhi@businesslayers.com>  |
	  |       cc:       Gearard Woods/Irvine/IBM@IBMUS, <conrada@microsoft.com>, <mattleib@microsoft.com>,                           |
	  |        <adrian.viego@businesslayers.com>, <Doron_Cohen@bmc.com>, "Steve Anderson" <sanderson@opennetwork.com>,               |
	  |        <Yoav.Kirsch@businesslayers.com>, <rami_elron@bmc.com>                                                                |
	  |       Subject:  RE: SPML should be Schema+WSDL                                                                               |
	  |                                                                                                                              |
	  >------------------------------------------------------------------------------------------------------------------------------|
	
	
	
	
	Edwin,
	
	First of all, a general purpose solution where the PST vendors just
	write any generic WSDL and XML Schema is not practical. That is not what
	Gerry is proposing, if I understand him correctly (Gerry, please correct
	me if I misrepresent this).
	
	Even with Gerry's proposal, the PST vendors would still need to know the
	specific SPML protocol and its semantics. The meta-data would still need
	to be defined and transmitted in an SPML specific fashion. The fact that
	you would use XSD to define the meta-data does not alleviate that. All
	the available tools out there will not directly support this.
	
	While Gerry's proposal is interesting and more flexible, it appears be
	more difficult for both the PST and PSP vendors to implement. There are
	several issues that will make that so:
	
	- How do we support using an open-ended meta-data mechanism such as XML
	Schema, but restrict it in a way that supports some level of
	interoperability?
	
	- How do we support filtered searching when the meta-data is so
	flexible?
	
	
	So far, I interpret Gerry's proposal to be in a nutshell (Gerry, again,
	please correct me if I misrepresent this):
	
	- make the protocol in terms of high-level provisioning operations
	rather than federated naming operations
	
	- define the provisioning meta-data in XML Schema rather than a protocol
	specific mechanism
	
	I don't believe that these approaches are going to solve the problem you
	are referring to.
	
	Let's leave theory aside for the moment and talk about practical issues.
	
	Netigrity and Business Layers have announced a demo of the current SPML
	spec at the next RSA conference. I also know of several other companies
	that are currently working on implementations, but have not announced
	them yet. Darran is working on setting up a Burton interop event in July
	similar to the one on SAML last year. There are draft specs on the web
	site. The analysts are starting to write about SPML and include it in
	their presentations. Other standards bodies are looking at what we have.
	Darran has indicated the Waveset would open source an SPML web service
	client in Java. OpenNetwork Technologies is looking at open sourcing a
	.NET SPML web service. All this things enhance adoption.
	
	If we start over, all that goes away and we will be 6-12 months away
	from where we are now. That will only hinder PST support, not help it.
	
	Even Gerry concedes that the current approach will work, but he believes
	his approach is superior. Even if you assume that, is that worth
	flushing a year worth of progress? Is it worth delaying the spec another
	6-12 months. Is it worth destroying the credibility that the PS TC has
	with Burton and the other analysts? Is it worth tanking the work
	companies have already done to support it in their products.
	
	It would be one thing if the current spec was not feasible. Everyone
	agrees that it is. It also seems to be garnering support in the industry
	and I see no reason why it would not be adopted, which is ultimately the
	most important factor.
	
	BTW, why are we discussing this off the SPML mail list?
	
	Jeff Bohren
	Product Architect
	OpenNetwork Technologies, Inc
	
	
	-----Original Message-----
	From: DeSouza, Edwin [mailto:edesouza@jamcracker.com]
	Sent: Friday, February 28, 2003 12:17 PM
	To: Jeff Bohren; Darran.Rolls@waveset.com;
	Gavenraj.Sodhi@businesslayers.com
	Cc: gewoods@us.ibm.com; conrada@microsoft.com; mattleib@microsoft.com;
	adrian.viego@businesslayers.com; Doron_Cohen@bmc.com
	Subject: RE: SPML should be Schema+WSDL
	
	Jeff,
	I don't have a problem with the UseCases that SPML addresses -- my issue
	is the skills/tools required to be successful with SPML.  We should
	assume engineers+Tools will know XML Schema and WSDL.  That's all.  Why
	make them and their tools also deal with yet another thing.
	
	Example1:  Assume companies like the idea of centralized Provisioning to
	all their internal applications.   Lets say they buy a commercial
	Provisiong product to do the centralized part.  Now they need to go and
	add Provisioning APIs to all their existing applications.   Same applies
	to all their New applications.   MUCH easier sell if "your engineers who
	do normal XML Schema and WSDL and their favorite tools" is all you need
	to get these applications to be SPML enabled.
	
	Example2:  Same applies to all the MSPs/ASPs.  They don't want their
	engineers to go learn something sooo specialized.
	
	Provisioning Vendors:  If 1+2 is easy, then the need for centralized
	Provisioning products will be much bigger.
	
	At Jamcracker, we continuously face 1+2, and it is hard enough to
	convince folks to add Provisioning APIs.  Why add an extra hurdle.
	
	Regards,
	Edwin.
	(Background: In a previous life was the founding Product Manager of
	Borland JBuilder ver 1,2,3,4 and Delphi before then.  So, I know a
	little bit about Tools/IDEs).
	
	
	
	
	
	-----Original Message-----
	From: Jeff Bohren [mailto:jbohren@opennetwork.com]
	Sent: Thursday, February 27, 2003 7:52 PM
	To: DeSouza, Edwin; Darran.Rolls@waveset.com;
	Gavenraj.Sodhi@businesslayers.com
	Cc: gewoods@us.ibm.com; conrada@microsoft.com; mattleib@microsoft.com;
	adrian.viego@businesslayers.com; Doron_Cohen@bmc.com
	Subject: RE: SPML should be Schema+WSDL
	
	
	Not to be picky, but OASIS is not just limited to web services and
	neither is the PS TC. The committee has already agreed to a SOAP/HTTP
	(i.e. web service) binding and a file binding. There will likely be more
	bindings to follow after the 1.0 specification.
	
	The intention has allways been to produce and XML Schema that is used
	for both the SOAP/HTTP and the file bindings, and a WSDL definition for
	the SOAP/HTTP Binding.
	
	Is there anything in the JamCracker business model that can not be
	supported using the current SPML draft spec?
	
	Jeff B.
	
	
	             -----Original Message-----
	             From: DeSouza, Edwin [mailto:edesouza@jamcracker.com]
	             Sent: Thu 2/27/2003 7:57 PM
	             To: Darran.Rolls@waveset.com;
	Gavenraj.Sodhi@businesslayers.com
	             Cc: gewoods@us.ibm.com; Jeff Bohren; conrada@microsoft.com;
	mattleib@microsoft.com; adrian.viego@businesslayers.com;
	Doron_Cohen@bmc.com
	             Subject: SPML should be Schema+WSDL
	
	
	             Darran,  Gavenraj,
	             We had a lot of discussion about this early on.  I even
	suggested basing SPML on SAML (rther than DSML)  But, that was still a
	bad solution.
	
	             Now, I saw this post from Gearard Woods and I cannot be more
	emphatic in agreeing with his idea for SPML below.  Absolutely right
	on!!!
	
	             My 3 years experience (as an ASP Aggregator)
	selling/provisioning 30+ MSP/ASP Web-based applications and WebServcies:
	             --  Gearard is describing the right Provisioning solution --
	An
	XML Schema with WSDL.
	
	             SPML is early enough for you to make this change.  And, at
	OASIS, standards are for WebServices first.
	
	             regards,
	             Edwin DeSouza,
	             Director, Product Management,
	             Jamcracker, Inc.
	
	
	
	http://lists.oasis-open.org/archives/provision/200302/msg00078.html
	
	             "....I also like the direction some other specifications have
	gone with their definition of the basic message schema in XML-Schema and
	then a separate binding into WSDL.  That's exactly what I would like to
	see.  Those specifications have targeted their messages to the domain
	and publish the interface using WSDL. To state that you are following
	that lead is to ignore the fact that you are repackaging a directory
	protocol which,  to repeat myself again, is the brunt of my objection."