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] | [Elist Home]


Subject: RE: [provision] Reuse in SPML


Gerry,
 
The current SPML Schema approach does support defining attribute syntax. In the draft_pstc_schema_schema_03.xsd the element for the AttributeDefinition is defined as:
 
  <xsd:complexType name="AttributeDefinition">
   <xsd:sequence>
    <xsd:element name="properties" type="Properties" minOccurs="0" maxOccurs="1"/>
   </xsd:sequence>
   <xsd:attribute name="name" type="dsml:AttributeDescriptionValue" use="required"/>
   <xsd:attribute name="description" type="xsd:string" use="optional"/>
   <xsd:attribute name="multivalued" type="xsd:boolean" use="optional" default="false"/>
   <xsd:attribute name="type" type="xsd:string" use="optional" default="xsd:string"/>
 </xsd:complexType>
 
Where the attribute named type represents the syntax. The normative values for this is the xsd strings representing attributes types (sxd:string, xsd:boolean, etc).
 
We did discuss ways of making the AttributeDefinition element more expressive, but no one has put forth any proposals on how to do it. If this was more expressive, perhaps even using more of the xml schema capabilities, would that make the proposed spec more acceptable to you?
 
As far as finding the schema, there is no root DSE required. The starting point would be the web service URL itself. If the url is known (which obviously it has to be), then all the schemas for an SPML service would be returned in response to a SchemaRequest message. If a specific schema is needed it can be retrieved by specifying the schema identifier. We are not following the LDAP V3 approach of returning schema in response to a search.
 
You mentions other specification that work as you propose. Which ones are they? I think if I could see some concrete examples I would understand your concerns better. The SPML SOAP/HTTP Binding will consist of a combination of an WSDL description and an XML Schema defintion, with associated normative specifications. The solution you are proposing would be the same, but it seems that you want to define the provisioning meta-data totally in the WSDL for a specific provisioning service type, rather than in a protocol specific meta-data mechanism as we have done in SPML. I would be interested in seeing some examples of that approach, as I am not aware of any.
 
Jeff B.

 

	-----Original Message----- 
	From: Gearard Woods [mailto:gewoods@us.ibm.com] 
	Sent: Thu 2/27/2003 3:04 PM 
	To: Jeff Bohren 
	Cc: provision@lists.oasis-open.org 
	Subject: RE: [provision] Reuse in SPML
	
	





	Jeff,
	It sounds to me like you didn't read my response thoroughly and are
	assuming that I haven't read the SPML schema documents.  Let me rephrase my
	objection.  Even if there is an agreed upon standard schema as there is for
	LDAP, you are still constrained by the expressive limitations of the schema
	language.  This is as true for SPML schema as it is for LDAP.  My example,
	you didn't seem to notice,  was stated in SPML schema, not LDAP schema - I
	know the difference even though it is slight.  Since we're on the subject,
	SPML even loses some of the expressiveness of LDAP schema in that there
	seems to be no way to specify syntax or matching rules.  Not that I'm in
	love with those concepts because, again, they are defined in documents that
	must be ferreted out (or known about beforehand)  rather than being
	available for immediate interpretation by tools.
	
	As far as a root DSE and controls go, I would argue that if there is no way
	for a tool to determine any metadata about an element of the protocol then
	it doesn't belong there.  I would ask the same question about determining
	the schema for an entity in the absence of a root DSE or the requirement
	for a subschemasubentry attribute.  Does SPML mandate the use of
	subschemasubentry or is SPML schema simply declarative and how you go about
	getting it outside the scope of the spec?
	
	As I'm sure you know, we also make extensive use of directory based
	protocols for provisioning and I don't see the need to restate that or
	OpenNetwork's commitment to DSMLv2.  What would be more interesting to me
	would be for you to assure me that you have never run into any limitations
	in your use of DSML or LDAP:  No XML documents as attribute values;  No
	Java serialized objects as attribute values because you were just stuck and
	there was no other way.
	
	You seem to be completely missing my point about WSDL. and I can certainly
	be more specific, but 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.
	
	Obviously SPML must go beyond a lot of the existing simple services out
	there because it must allow the definition of schema.  This is another
	conerstone of my argument and you cannot dismiss it by claiming that
	someone could define a class with a particular attribute with a particular
	syntax if they want a suspendable account or some other feature.  Sorry but
	that doesn't jive with your arguments about semantics and it doesn't
	satisfy my need for a provisioning centric API with en expressive schema
	language.
	
	The questions I'm asking will be asked by others when you unveil this
	proposal to the world at large.  To be honest, the dismissive "don't worry
	about it, it will easily work" platitude is OK for me but doesn't win
	support when real problems have to be confronted and solved.  As I have
	said before, we should be on the same side.
	Gerry
	
	
	
	
	|---------+---------------------------->
	|         |           Jeff Bohren      |
	|         |           <jbohren@opennetw|
	|         |           ork.com>         |
	|         |                            |
	|         |           02/27/2003 11:15 |
	|         |           AM               |
	|         |                            |
	|---------+---------------------------->
	  >------------------------------------------------------------------------------------------------------------------------------|
	  |                                                                                                                              |
	  |       To:       provision@lists.oasis-open.org                                                                               |
	  |       cc:                                                                                                                    |
	  |       Subject:  RE: [provision] Reuse in SPML                                                                                |
	  |                                                                                                                              |
	  >------------------------------------------------------------------------------------------------------------------------------|
	
	
	
	
	Gerry,
	
	I apologize for not being clear on this, but root DSEs are not part of
	SPML. Although the control element is allowed as past of the DSMLMessage
	definition, this is outside of the scope of SPML. If that bothers you we
	could easily remove the reuse of the DSMLMessage type. Would you like me
	to propose that at the next meeting? It would have no impact on the spec
	to do that. Also, we do not use LDAP Schema in SPML. There is an SPML
	Schema mechanism.
	
	I'm sorry, but I still don't see the value in throwing away what we have
	so far to start from scratch along a path that may never yield any
	useful results. I would still rather go with something I know will work.
	
	Could you do provisioning with just DSML v2? Absolutely, and OpenNetwork
	Technologies will continue to support that in addition to SPML. In fact
	my original "SPML based on DSML v2" proposal was much closer to DSML v2
	than SPML is today. As committee we added the additional functionality
	to support areas that DSML v2 was deemed insufficient.
	
	The SPML effort is not intended to be limited to SOAP/HTTP. That is one
	of two supported bindings (the other being the File Binding) in the 1.0
	spec. There will probably be other bindings defined post 1.0. If we
	build the spec around WSDL, then we are limited to the SOAP/HTTP
	binding. I don't find that acceptable.
	
	If you believe that WSDL/XML Schema is the right solution, go ahead and
	use it. The PS TC has published a XML Schema for SPML and will likely
	publish a WSDL definition as part of the SOAP/HTTP Binding.
	
	Note that the approach we are taking for SPML of defining the protocol
	in the document body schema (with supporting normative restrictions)
	rather than as WSDL/XML Schema is the same approach being taken by DSML,
	SAML, XKMS, OMI, UDDI, etc. Are there any standards bodies taking the
	approach of defining the protocol in terms of WSDL/XML Schema only? It
	is an interesting idea, but it seems risky to me at this stage.
	
	The intention is that WS-Security be used with the SPML SOAP/HTTP
	Binding. That is why we explicitly avoided dealing with authentication
	issues in that binding. There will be recommendations around WS-Security
	in the SOAP/HTTP Bindings document.
	
	The SPML Batch Request is not intended to imply transactions, although
	an implementer could certainly make them transactional. Instead it is
	intended to support the asynchronous request/response model, something
	that DSML v2 lacked.
	
	Now for the suspend/restore example. The PSTC (or someone else) could
	define a standard schema that defines an object class for accounts that
	can be suspended. For this example, call it suspendableAccount. This
	class would define an accountStatus attribute. Any PST that supports
	suspendable accounts would add this object class and a parent class of
	the PSTs object class.
	
	The PSP, when trying to suspend an account would look to see of the
	account type had suspendableAccount as a parent class. If it did, it
	would use the accountStatus attribute.
	
	This is just speculation, so don't get hung up on the details. I'm not
	sure how this problem will actually be solved, but it is easily
	solvable.
	
	
	Jeff Bohren
	Product Architect
	OpenNetwork Technologies, Inc
	
	
	-----Original Message-----
	From: Gearard Woods [mailto:gewoods@us.ibm.com]
	Sent: Thursday, February 27, 2003 12:30 PM
	To: Jeff Bohren
	Cc: Conrad Agramont; provision@lists.oasis-open.org
	Subject: RE: [provision] Reuse in SPML
	
	
	
	
	
	Jeff,
	You'll have to tell me how LDAP schema conveys the concept of suspending
	an
	account using a specific value of an arbitrary attribute like
	accountStatus.  Let me try.  An LDAP (SPML) schema for accountStatus
	might
	look roughly like:
	...
	<AttributeDefinition xmlns="urn:oasis:names:tc:SPML:1:0:schema"
	name="accountStatus" multivalued="false" type="xsd:string"/>
	...
	OK, so I can look at at this document and see that there is a
	single-valued
	attribute called accountStatus that is a string.  Yesterday we were
	talking
	about semantic predictability, this tells me nothing about semantics and
	just a little about syntax.  I wouldn't call that successful.  Compare
	instead what some kind of service level API definition might look like,
	were we instead to use XML-shema:
	...
	<xsd:attribute name="accountStatus" use="optional">
	      <xsd:simpleType>
	            <xsd:restriction base="xsd:string">
	                  <xsd:enumeration value="supend"/>
	                  <xsd:enumeration value="restore"/>
	            </xsd:restriction>
	      </xsd:simpleType>
	</xsd:attribute>
	...
	Now I'm not suggesting that this is a real part of some API, it's just
	an
	example - I could just as easily have concocted a WSDL API that included
	a
	suspend method.  My point is that already, to a human reader, this
	conveys
	some meaning.  The semantics of this attribute leap out of the page.  In
	addition I have tools that can generate classes from this, in many
	langauges, that I can use directly and that now model the domain.  You
	can
	throw examples like SNMP around until we're all blue in the face, and
	counter examples like CIM but you know as well as I do that the success
	or
	failure of a given specification relies heavily on adoption, momemtum
	and,
	dare I say, fashion as much as anything else.  I'm not saying that's
	what
	happened in the cases you mention but if you really want some examples
	why
	not look at WSDL?  Is Microsoft barking up the wrong tree with .Net I
	wonder?  IBM's emphasis on Web Services must be misdirected.  What about
	the explosive growth of Portal servers? What about the body of work that
	is
	growing up around these standards such as WS-Security, WSTransactions?
	The
	list goes on.  It's my belief that the SPML can ride this wave and be
	counted or look backwards to SNMP and LDAP, use the limited schema
	facilities they have to offer, and be regarded as difficult and
	outdated.
	Why should I have to use different tools and switch cognitive gears when
	I'm faced with dealing with SPML when I'm merrily integrating disparate
	systems that rely on WSDL/XML-Schema?
	
	You keep referring to the simple, proven model that works and yet there
	are
	so many things, other than schema, carried over from LDAP/DSML into the
	current proposal that are not simple nor have they proven to be useful
	to
	provisioning.  You never answered my question about server requirements
	for
	a root DSE.  How will I discover what controls are supported by a PSP?
	Why
	should I have to?  Even if I do, what does a control mean?  How do I get
	even a syntactic description of one, read an RFC? The semantic behaviour
	of
	batch requests in SPML differs from DSMLv2 as far as I can tell because
	you
	are implying transactional semantics in a batch request which, correct
	me
	if I'm worng, is not part of DSMLv2.
	
	If acceptance is what you are after then a specification that fills the
	vacuum for a provisioning API is what we should be aiming for.  If SPML
	differs only slightly from DSMLv2, and raises more questions about
	inappropriate directory type behaviour and limited schema, why should I
	adopt it in favour of DSMLv2?
	Gerry
	
	
	
	
	|---------+---------------------------->
	|         |           Jeff Bohren      |
	|         |           <jbohren@opennetw|
	|         |           ork.com>         |
	|         |                            |
	|         |           02/27/2003 05:13 |
	|         |           AM               |
	|         |                            |
	|---------+---------------------------->
	
	>-----------------------------------------------------------------------
	-------------------------------------------------------|
	  |
	|
	  |       To:       Gearard Woods/Irvine/IBM@IBMUS
	|
	  |       cc:       Conrad Agramont <conrada@microsoft.com>,
	provision@lists.oasis-open.org                                      |
	  |       Subject:  RE: [provision] Reuse in SPML
	|
	  |
	|
	
	>-----------------------------------------------------------------------
	-------------------------------------------------------|
	
	
	
	
	
	There is a very easy way to convey the meaning of concepts like
	accountStatus. It can be done through the use of standard schemas.
	Although LDAP has successfully used that concept, the best example I
	have for that is SNMP. SNMP has a simple protocol that defines
	operations and data types. True interoperability is not achieved in SNMP
	via the protocol but through the use of standard schemas that define
	what the semantics of protocol for specific services.
	
	This approach has led SNMP to achieve the highest level of adoption and
	interoperability of any management protocol while it's more fully
	feature competitors such as CMIP are dead.
	
	By counter example, the WEBM/CIM specification from the DMTF does model
	real world objects. Although there are a lot of things I like about
	WEBM, and it has been implemented by MS and a few others, it has not
	achieved widespread industry adoption. And I don't expect it to do so
	anytime soon. WEBM is everything you describe, but no one wants to
	implement it.
	
	I would rather stick with a simple proven model that we know can work
	rather than try to invent a new concept that may never be accepted. Sure
	there are limitations, but by using proven model we know what those
	limitations are and can plan accordingly. If we start from scratch, we
	most likely won't know what the limitations are until it is too late.
	
	Jeff Bohren
	Product Architect
	OpenNetwork Technologies, Inc
	
	
	-----Original Message-----
	From: Gearard Woods [mailto:gewoods@us.ibm.com]
	Sent: Thursday, February 27, 2003 2:35 AM
	To: Jeff Bohren
	Cc: Conrad Agramont; provision@lists.oasis-open.org
	Subject: RE: [provision] Reuse in SPML
	
	
	
	
	
	Jeff,
	I know you've worked hard on this spec and I'm sorry to drop in at the
	last
	minute only to be criticial.  After all, the window for submissions came
	and went and there was a resounding silence from our corner.  In the end
	though, competitive pressures aside, I think we're all on the same side.
	We all want something that will work, as you point out, and beyond that
	for
	my part, I want something that fits in with the tools and technologies
	that
	I anticipate I will be using over the next few years.  I would prefer
	that
	it be as elegant as is possible in a design by committee scenario, as
	clean
	and simple as possible so that it can be understood and implemented, and
	appropriate to the domain as a service interface should be.
	
	There are many people on the committee I'm sure who have direct
	practical
	experience with directory based protocols in provisioning.  My
	experience
	with them in a provisioning context is what leads me to conclude that
	it's
	more by chance and, as Conrad said, for lack of something better that we
	use them at all.  Of course they work.  We're engineers, we make things
	work even if it takes pieces of string and double sided tape but that's
	not
	the point.  The point is that we have the opportunity, the tools, the
	technology and the market interest to make something better.
	Directories
	like X.500 were created way back in the big iron days to solve a
	specific
	problem.  The fact is that it wasn't a provisioning problem, it was a
	directory problem.  Provisioning is becoming a term that people
	recognize
	more and more as something that is distinct, and something that has
	growing
	importance.  Building a management or provisioning interface into
	software
	is a pivotal part of the product's ability to integrate into your
	enterprise and thereby part of its appeal and value.  Of course XML is
	seen
	as the answer to all integration problems but we can be more specific:
	WSDL and XML-Schema are here to stay because there is huge momentum
	behind
	them in the form of your second point, industry acceptance, which
	translates into toolkits, and a growing set of interoperable and
	comlementary specifications that everyone can take advantage of to make
	their job easier and their systems more robust.
	
	I like your semantic predictability argument despite its cognitive
	dissonance.  All joking aside, you seem to be assuming that it's not
	possible to create an interface that exhibits an equal measure of
	predictability on an equally predictable model.  In fact, I would argue
	that a more predictable model and interface could be created when the
	the
	entities involved reflect real world objects rather than a set of
	attributes and values, and operations that reflect provisioning
	operations
	rather than add, delete, modify.  Take a specific problem common in
	provisioning systems: suspending an account.  I know some provisioning
	systems that use an attribute modification (say, the setting of an
	attribute to some value, e.g. accountStatus = "1") to effect this
	operation.  In the world of LDAP and LDAP schema, there is no way to
	communicate this semantic meaning and the current SPML will continue
	that
	tradition.  Where is predictability when I buy multiple products with
	reams
	of documentation and have to wade through it all to discover how to
	suspend
	an account?  You can see where I'm going.  Comprehensive schema,
	self-describing systems, and APIs that make sense to humans are all the
	rage for good reason and I think you've hit the nail on the head - it's
	semantic predictability.
	
	I'm not suggesting that SPML be a rehash of WSDL or consist exclusively
	of
	extended operations, that wouldn't do either.  But there is a definite
	need
	that we're all feeling for a usable provisioning API that will fit
	snugly
	with the Web Services we're using and creating and is all about
	provisioning.  The question that we're being asked as practitioners in
	the
	field is what should that look like?  X.500 wouldn't be my answer.
	Gerry
	
	
	
	|---------+---------------------------->
	|         |           Jeff Bohren      |
	|         |           <jbohren@opennetw|
	|         |           ork.com>         |
	|         |                            |
	|         |           02/26/2003 07:08 |
	|         |           PM               |
	|         |                            |
	|---------+---------------------------->
	
	>-----------------------------------------------------------------------
	-------------------------------------------------------|
	  |
	|
	  |       To:       Conrad Agramont <conrada@microsoft.com>, Gearard
	Woods/Irvine/IBM@IBMUS                                      |
	  |       cc:       provision@lists.oasis-open.org
	|
	  |       Subject:  RE: [provision] Reuse in SPML
	|
	  |
	|
	
	>-----------------------------------------------------------------------
	-------------------------------------------------------|
	
	
	
	
	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>
	
	
	
	----------------------------------------------------------------
	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>
	
	
	
	
	----------------------------------------------------------------
	To subscribe or unsubscribe from this elist use the subscription
	manager: <http://lists.oasis-open.org/ob/adm.pl>
	
	
	
	



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


Powered by eList eXpress LLC