[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
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>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC